Recently somebody asked me some questions about when to use addError, and it is true that there is always an aura of mystery about when and how to use this Salesforce method. My idea in this blog post is try to explain addError uses with practical examples, in order that it is demystified.
Following with a previous post about triggers and order of execution, I want to review in this new post how the order of execution on a Visualforce page is. This time we need to distinguish between two different cases: Visualforce pages that perform a get request and those which perform a post request.
In this post I will explain how GET requests work. I will elaborate a second part of the post, talking about POST requests.
In this post I want to review the order in which things happen when I save a record in Salesforce. This is important to understand if you are an app builder who works automating processes as well as if you are a developer that writes trigger code. Both worlds will converge in the end and affect each other, so you have to bear in mind how Salesforce executes things internally to ensure a correct behaviour of your solution.
This time I want to talk a bit about CRUD & FLS in Salesforce. What do these acronyms mean? Well… it is the way that we have of allowing or restricting who can create, view, modify or delete objects and fields on the platform.
CRUD – Create / Read / Update / Delete
FLS – Field Level Security (visible, editable, hidden)
So, what’s the frightening Lightning Locker Service? It is a combination of security features that have been implemented for you in order your Lightning Components are secure, and other components don’t break yours! So, no frightening at all, right?