Winter ’22 release is here, and with it, new GA features that developers can use today, as well as developer preview, beta and pilots that you can try out. Last week I gave a talk to the Amsterdam Developer Group in which I went over all these features, explaining what they’re about, how to try them out, and where to find more information.Continue reading “Winter ’22 Highlights for Salesforce Developers”
This month I had the pleasure to present at several community groups to talk about the announcements and features showcased at TDX 2020. I spoke about Salesforce Functions, new Apex features, Code Builder and Lightning Web Runtime (including a demo!).Continue reading “TrailheaDX 2020 Global Gatherings”
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.Continue reading “Triggers and order of execution”
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)
This time I want to point out some weird behaviours I have learnt with the practice about datetimes in Salesforce. Did you know them?
1. Datetime fields do not store milliseconds.
Currently datetime fields don’t support millisecond precision. Even if you work with Datetime class (which do support millisecond precision), when you store them in database the milliseconds are lost.
This is a problem if you need to work with a high time precision, that can be worked around in some ways, for example storing the Unix time in a number field.
You can vote this related idea if you feel it is an important fact.