Business Logic and Automation

Flow Builder is THE main Salesforce automation tool. Workflow Rules and Process Builder are legacy and should not be used for new developments.

The 6 Flow types:

1. Screen Flow:
- Presents a visual interface (screens) to the user to collect data or guide a process.
- Launched from: buttons, Quick Actions, Lightning Pages, utilities, Experience Cloud pages.
- Supports: inputs/outputs, screen navigation, on-screen validation.
- Use case: onboarding forms, record creation wizards, guided assistants.

2. Record-Triggered Flow (Before Save):
- Executes BEFORE the record is saved to the database.
- Does NOT consume DML operations when updating fields on the triggering record (most efficient).
- Can only modify the record that triggered the flow.
- CANNOT: create/update other records, send emails, call Apex, use interaction elements.
- Use case: auto-populate fields, normalize data before saving.

3. Record-Triggered Flow (After Save):
- Executes AFTER the record is saved to the database.
- CAN: create/update/delete other records, send emails, call subflows.
- Consumes DML operations for each database operation.
- Use case: create related records, send notifications, update parent records.

4. Record-Triggered Flow (Async After Save):
- Asynchronous variant of After-Save. Executes in a separate transaction.
- Resolves the MIXED_DML_OPERATION error (when you need to modify setup and non-setup objects).
- Doesn't block the user — executes in the background.
- Use case: update User records alongside business records.

5. Schedule-Triggered Flow:
- Runs at a scheduled time and frequency (daily, weekly).
- Queries records meeting criteria and executes actions on them.
- Use case: send weekly reminders, update expired contract statuses, data cleanup.

6. Platform Event-Triggered Flow:
- Triggered when a Platform Event is published.
- For asynchronous integrations and event-driven communication.
- Use case: receive events from external systems, process real-time updates.

Other types:
- Autolaunched Flow (No Trigger): Invoked programmatically from Apex, other flows, or as subflows. Has no automatic trigger or screens.

Capability summary table:

Capability	Screen	Before Save	After Save	Scheduled
User screens	✅	❌	❌	❌
Update same record	✅	✅ (0 DML)	✅	N/A
Create/Update other records	✅	❌	✅	✅
Send emails	✅	❌	✅	✅
Call Apex	✅	❌	✅	✅
Execution	Manual	Automatic	Automatic	Scheduled

Flow Builder uses visual elements connected to create process logic.

Logic Elements:
- Decision: Conditional branching (similar to IF/ELSE). Evaluates conditions and directs flow through different paths. Each outcome has criteria (All conditions met / Any condition met / Custom formula).
- Loop: Iterates over a collection of records. Processes one element at a time. NEVER put DML/SOQL inside a Loop (causes limit errors).
- Assignment: Assigns values to variables. Operators: Equals, Add, Subtract. Critical for: adding records to collections, modifying variable values.
- Wait: Pauses the flow until a time condition or Platform Event is met. Only available in Autolaunched Flows.

Data Elements:
- Get Records: Queries records from the database (equivalent to SOQL). Configurable by object, filter criteria, fields to retrieve, and sorting.
- Create Records: Inserts new records into the database.
- Update Records: Updates existing records. Can update: the triggering record, records obtained with Get Records, or records filtered by criteria.
- Delete Records: Deletes records from the database.

Screen Elements (Screen Flows only):
- Screen: Interactive screen with form components.
- Available components: Text Input, Number Input, Date Input, Picklist, Radio Buttons, Checkboxes, Display Text, File Upload, Lookup, Data Table, Section, Toggle.
- Screens can have custom validations preventing progression if conditions aren't met.

Action Elements:
- Action (Invocable Action): Executes predefined actions: send email, send custom notification, Chatter post, invoke Apex, call subflow.
- Subflow: Calls another Flow as a reusable module. Allows passing input variables and receiving output variables.

Flow Variables:
- Simple variables: Text, Number, Currency, Boolean, Date, DateTime, Picklist.
- Record Variables: Store a complete record from an object.
- Collection Variables: Store multiple records (collections/lists). Essential for the bulkification pattern.
- Constants: Values that don't change during execution.
- Formulas: Calculate dynamic values within the flow.
- Choice / Collection Choice Set: For selection components in screens.

Flow Resources (available throughout the flow):
- $Record: The record that triggered a Record-Triggered Flow.
- $Record__Prior: The PREVIOUS values of the triggering record (After-Save only).
- $Api: API session information.
- $Flow: Running flow metadata.
- $GlobalConstant.EmptyString: Empty string (useful for comparisons).
- $User: Information about the user running the flow.
- $Profile: User's profile information.

Validation Rules evaluate a boolean formula. If the formula returns TRUE, the save is BLOCKED and an error message is displayed.

Fundamental concept: The formula describes the ERROR condition, not the valid condition. If you want a field to be required when Stage is 'Closed Won', the formula should evaluate to TRUE when the field is empty AND Stage is 'Closed Won'.

Most asked formula functions on the exam:

Function	Description	Example
ISBLANK(field)	TRUE if empty	ISBLANK(Email)
ISPICKVAL(pick, 'val')	Compares picklist	ISPICKVAL(Stage, 'Closed Won')
PRIORVALUE(field)	Previous value	PRIORVALUE(Status__c)
ISCHANGED(field)	TRUE if changed	ISCHANGED(OwnerId)
ISNEW()	TRUE if creation	ISNEW()
CONTAINS(txt, 'sub')	Contains substring	CONTAINS(Name, 'Test')
REGEX(txt, 'pattern')	Regular expression	REGEX(Phone, '[0-9]{10}')
LEN(text)	Text length	LEN(Description) > 500
NOT(condition)	Negates condition	NOT(ISBLANK(Email))
$Profile.Name	Profile name	$Profile.Name != 'System Admin'
$User.Id	Current user ID	For user exceptions

Practical examples (exam-style):

*Example 1: Block Opportunity close without Description:*

AND(
  ISCHANGED(StageName),
  ISPICKVAL(StageName, 'Closed Won'),
  ISBLANK(Description)
)

*Example 2: Only Admin can change owner:*

AND(
  ISCHANGED(OwnerId),
  $Profile.Name != 'System Administrator'
)

*Example 3: Phone must have exactly 10 digits:*

AND(
  NOT(ISBLANK(Phone)),
  NOT(REGEX(Phone, '[0-9]{10}'))
)

Error message location:
- Top of Page: Error appears at the top of the page.
- Field Level: Error appears next to the specified field. Easier for the user to identify the problem.

Important rules:
- PRIORVALUE(), ISCHANGED() only work on updates, NOT on creation.
- ISNEW() only works on creation.
- Validations execute BEFORE Before-Save Flows.
- An object can have multiple active validation rules.
- Validation rules apply on ALL channels: UI, API, Data Loader, Flow.

Approval Processes automate record approval through configurable steps. They are one of the most tested areas on the PAB exam.

Approval Process Components:

1. Entry Criteria: Conditions the record must meet to enter the process (e.g., Amount > 10,000).
2. Approver(s): Who approves at each step. Options:
- Manager: The submitter's manager (defined in User record's role hierarchy).
- Queue: An approval queue.
- Specific User: A specific user.
- Related User: A user in a record field (e.g., the 'Manager__c' field).
3. Steps: One or more sequential approval steps. Each step can have different approvers and criteria.
4. Actions:
- Initial Submission Actions: Execute when the record is submitted for approval (e.g., lock editing, change Status to 'Pending').
- Approval Actions: Execute when approved (e.g., change Status to 'Approved', send email).
- Rejection Actions: Execute when rejected (e.g., change Status to 'Rejected', notify requester).
- Recall Actions: Execute when the request is recalled.
- Final Approval Actions / Final Rejection Actions: Execute at the end of ALL steps.

Record Lock:
By default, when a record enters an Approval Process, it is locked for editing (Record Lock). Only the current approver and administrators can edit it. This is configurable.

How to start an Approval Process:
- Manual: User clicks 'Submit for Approval' on the record.
- Automatic: A Flow can invoke a 'Submit for Approval' action.
- Apex: Code can submit records for approval programmatically.

Approval routing types:
- Unanimous: ALL assigned approvers must approve.
- First Response: The FIRST to respond decides (approve or reject).

Parallel Approvals:
In a single step, multiple approvers can be assigned to review simultaneously. With 'Unanimous' routing, all must approve. With 'First Response', the first to respond determines the outcome.

Practical example:
Opportunity Discount:
- Entry Criteria: Discount__c > 20%
- Step 1: Direct Manager approval.
- Step 2: If Discount > 40%, VP of Sales approval.
- Initial Actions: Lock record, Status = 'Pending Approval'.
- Final Approval: Status = 'Approved', send confirmation email.
- Final Rejection: Status = 'Rejected', notify salesperson.

Important limitations:
- An object can have multiple Approval Processes, but a record can only be in one at a time.
- Approval Processes CANNOT be created inside Flow Builder — they are configured in Setup.
- Records locked by an Approval Process can ONLY be edited by the current approver or administrators (unless lock is disabled).

Understanding the Order of Execution is fundamental for diagnosing problems and designing correct solutions. This is the order Salesforce processes a record when saved:

Simplified order for the PAB exam:

1. System Validation Rules: System validations (required fields, format, uniqueness).
2. Before Triggers (Apex): Triggers executing before save.
3. Custom Validation Rules: Validation rules you created.
4. Duplicate Rules: Duplicate verification.
5. Before-Save Record-Triggered Flows: Before Save type flows.
6. Record saved to database (but not committed yet).
7. After Triggers (Apex): Triggers executing after save.
8. Assignment Rules: Assignment rules (Lead/Case).
9. Auto-Response Rules: Automatic responses.
10. After-Save Record-Triggered Flows: After Save type flows.
11. Entitlement Rules
12. Roll-Up Summary Fields: Recalculated on the parent object.
13. Cross-Object Workflow/Flow updates: Updates on related objects.
14. Criteria-Based Sharing Rules: Sharing rule evaluation.
15. DML committed to database: Changes are permanently confirmed.
16. Post-Commit Logic: Email sending, future calls.

Key exam points:

Question	Answer
What executes first: Validation Rules or Before-Save Flow?	Validation Rules (step 3) before Before-Save Flow (step 5)
What executes first: Before Trigger or Validation Rule?	Before Trigger (step 2) before Validation Rule (step 3)
When does After-Save Flow execute?	After the record is saved to DB (step 10)
When are Roll-Up Summaries recalculated?	After After-Save Flows (step 12)
When are emails actually sent?	In Post-Commit (step 16), after everything is confirmed

Practical implication: If a Before-Save Flow depends on a value changed in a Validation Rule or Before Trigger, that change will have already occurred. But if an After-Save Flow updates a field, Validation Rules do NOT re-execute for that update.

Flow best practices are constantly asked on the exam. Memorizing them is mandatory.

1. NEVER DML/SOQL inside a Loop:
The most important rule. If you put Get Records, Create, Update, or Delete inside a Loop, each iteration consumes a SOQL or DML operation. With 200 records, this causes immediate errors.

INCORRECT Pattern ❌:

Loop (Accounts collection)
  └── Get Records (find Contacts for each Account)  ← SOQL inside loop
  └── Update Records (update each Contact)           ← DML inside loop

CORRECT Pattern ✅ (Bulkification):

Get Records (all related Contacts) ← SOQL outside loop
Loop (Contacts collection)
  └── Assignment (modify and add to collection)
Update Records (entire collection) ← DML outside loop

2. One Record-Triggered Flow per object:
Salesforce recommends consolidating all automatic logic for an object into ONE single Record-Triggered Flow. Inside the flow, use Decision elements to direct logic based on criteria.

Benefits:
- Avoids execution order conflicts between multiple flows.
- Easier to maintain and debug.
- Better performance.

3. Use Before-Save whenever possible:
To update fields on the triggering record, use Before-Save (0 DML). Only use After-Save when you need to affect OTHER records.

4. Implement Guard Clauses:
At the start of the flow, verify conditions and use Decision elements to exit early if criteria aren't met. Avoids unnecessary executions.

5. Use Entry Conditions:
Configure entry conditions on Record-Triggered Flows so they only activate when needed. Example: only execute when Status__c is 'Closed'.

6. Avoid infinite recursion:
If an After-Save Flow updates the same record, it can re-fire. Use the flow configuration option: "A record update that satisfies the condition requirements" vs "Every time a record is updated" vs "Only if the record that triggered the flow is updated to meet the condition requirements."

7. Testing:
- Use Debug in Flow Builder to test with specific records.
- Test with bulk data (Data Loader) to validate limits aren't exceeded.
- Flows run in the user context — consider permissions.

8. Documentation:
- Name flows descriptively: Account - Before Save - Auto-populate Fields.
- Use Description on each flow element to explain its purpose.
- Name variables with prefixes: var_, col_, rec_ for clarity.

9. Error handling:
- In Screen Flows, use Fault Connectors to capture errors and show friendly messages.
- Configure Fault Path on data elements to handle DML errors gracefully.

10. Subflows for reuse:
Extract common logic into Autolaunched Flows invoked as Subflows. This promotes reuse and reduces duplication.