Validation Rules

💬 In plain words: A Custom Permission is a simple yes/no flag you attach to users, which your code and flows can check — like a feature switch per person. Use it instead of hardcoding profile names in logic. 📌 Example: Validation rule blocks editing closed Cases — but the audit team must edit them. Create Custom Permission Edit_Closed_Cases , add NOT($Permission.Edit_Closed_Cases) to the rule, and assign it to auditors via a permission set. No profile checks in formulas! 🎬 Real-Life Example: Bypassing a Validation Rule Imagine you have a rule: no one can discount an Opportunity by more than 20%. But the VP of Sales needs to override this rule when closing major deals. The Old/Bad Way (hardcoding): Write a validation rule checking profile names: Discount__c > 0.20 && $Profile.Name != 'System Administrator' && $Profile.Name != 'VP of Sales' . Why this is bad: If Regional Manager...

If you’ve spent any time building automation in Salesforce, you’ve probably heard this Golden Rule: "Always update fields on the triggering record using a Before-Save Flow!" It sounds simple enough, but why is this rule so heavily emphasized? What actually happens under the hood when you update a record inside an After-Save Flow instead? Does Salesforce rewind everything back to Step 1? Let’s lift the hood on the Salesforce Order of Execution, break down what happens during a record update in plain English, and look at how to build faster, cleaner automation. The Basics: The Salesforce "Assembly Line" Whenever a user clicks Save on a record, Salesforce doesn't just write the data to a database and call it a day. It passes the record through a strict, multi-step assembly line called the Order of Execution . Here is a simplified look at what happens in order: Loads the record and applies your new field values....

💬 In plain words: When you press Save, Salesforce runs a fixed assembly line: checks → before automation → save → after automation → related updates → commit. Half of all tricky bugs are just two steps of this line writing the same field. Learn the line once and those bugs become obvious. 📌 Example: A validation rule demands Discount ≤ 20%. A workflow field update later sets Discount = 25% — and saves fine, because workflow runs AFTER validation. Users can't break the rule; your own automation just did. That's why order matters. 🎬 Real-Life Example: The Field That Kept Changing Itself Back A Flow sets Priority__c to High for same-day parcels. Yet saved records keep showing Normal. The admin swears the Flow runs. The developer swears the trigger works. Both are right. The Old/Bad Way: The before-save Flow sets High. Then a before trigger — written two years earlier — recalculates Priority and overwrites it. Nobody ...