Read the blogpost I published in the Salesforce Developers blog.
Last week I was exploring the options to show a context sensitive pop-up in record detail pages. The pop-up needed to use the sObject name of the record that was being visualised in the detail page. I wanted this functionality to be available in classic and Lightning Experience. So I spent some time exploring the options that we have to do this. Are Lightning Components ready to fulfil my requirements?
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.