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.
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)
Lightning Connect is a Salesforce feature that allows integrations with external systems. Before Winter 16 release, it only read-only capabilities were provided. Since Winter 16, writable datasources were delivered, making Lightning Connect a very interesting option to think about.