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)
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.