Get Records, Loops, Collections and Decisions in Flow
5 minutes
5 Questions
In Salesforce Flow, four core building blocks enable data-driven automation and are essential knowledge for the Platform Administrator II exam. Get Records retrieves Salesforce records into a flow. You choose an object, define filter conditions, set sort order, and specify whether to store only the first record or all matching records. Results can be stored automatically in a flow-created variable or manually in a record variable (single record) or record collection variable (multiple records). You can also choose to store all fields or selected fields. A key best practice is to use Get Records outside loops to avoid hitting SOQL governor limits (100 queries per transaction). Collections are variables that hold multiple values of the same data type, such as text, numbers, or records. Record collection variables are the most common, typically populated by Get Records or assembled via Assignment elements using the 'Add' operator. Collections allow bulk processing and are critical for bulkification—for example, adding updated records to a collection inside a loop, then performing one Update Records element after the loop finishes, rather than executing DML on each iteration. Loops iterate over a collection one item at a time. Each iteration exposes a loop variable (the current item) that you can read or modify using Assignment elements. The loop has two paths: 'For Each Item' (executed per record) and 'After Last Item' (executed once when finished). Never place Get Records, Create, Update, or Delete elements inside a loop, as this risks governor limit failures. Decisions act as branching logic, similar to IF/ELSE statements. You define one or more outcomes with conditions using AND/OR logic or custom condition logic, plus a default outcome. Decisions route the flow based on record field values, variables, or formula results, and are often used within loops to evaluate each record. Together, these elements form the pattern: Get Records → Loop → Decision → Assignment → DML after loop.
Get Records, Loops, Collections and Decisions in Flow: The Complete Guide for the Salesforce Advanced Administrator Exam
Why This Topic Matters
Flow Builder is now the primary declarative automation tool in Salesforce. With Workflow Rules and Process Builder retired for new automation, the Advanced Administrator exam leans heavily on your ability to design efficient, scalable flows. The Advanced Process Automation section is one of the most heavily weighted areas of the exam, and almost every flow scenario question depends on four building blocks: Get Records (retrieving data), Collections (holding multiple records or values), Loops (iterating through collections) and Decisions (branching logic). If you understand how these elements interact, and especially how they relate to governor limits and bulkification, you can answer the majority of flow design questions with confidence. Expect questions that describe a business requirement and ask which element or combination of elements you should use, or that describe a failing flow and ask you to diagnose the design error.
1. Get Records
What it is: Get Records is a data element that queries the Salesforce database and returns one or more records that match your filter criteria. Behind the scenes, every Get Records element consumes one SOQL query from the transaction's governor limit (100 SOQL queries per synchronous transaction).
Key configuration options:
• Object – the object to query (for example, Contact).
• Filter Conditions – one or more conditions combined with AND, OR or custom logic. You can filter by field values, variables, formulas or the triggering record's fields (such as {!$Record.AccountId}).
• Sort Order – ascending or descending by a chosen field. Sorting matters when you select only the first record (for example, the most recent Opportunity).
• How Many Records to Store – Only the first record stores a single record variable; All records stores a record collection variable.
• How to Store Record Data – Automatically store all fields (recommended for simplicity), Choose fields and let Salesforce store them, or Choose fields and assign variables (advanced) where you map fields into existing variables.
• When no records are returned – by default the output variable is set to null. In the advanced manual-assignment mode you can choose to leave existing variable values unchanged.
Critical behaviour to remember:
• When Get Records finds nothing, the output variable (single record or collection) is null. You should test for this with a Decision using the Is Null = True operator before looping or referencing a field, otherwise the flow will throw an unhandled fault.
• Get Records returns records that the running user can see when the flow runs in user context; it returns all records when the flow runs in system context without sharing. Flow context is an exam favourite.
• A Get Records element placed inside a Loop executes once per iteration – this is the classic anti-pattern that leads to 'Too many SOQL queries: 101' errors.
2. Collections
What they are: A collection variable holds multiple values of the same data type. The most common types are record collection variables (a list of Account records, for example), and text, number, date or picklist collections. Get Records with 'All records' automatically produces a record collection variable.
Working with collections:
• Assignment element with the Add operator appends a record or value to a collection. This is how you build a list of records to update or create in bulk.
• Assignment element with Equals Count stores the number of items in a collection into a number variable – useful for Decisions such as 'Does the Account have more than 5 open Cases?'.
• Collection Filter element filters an existing collection in memory without a new SOQL query. Use it when you already have the records and need a subset.
• Collection Sort element sorts an existing collection and can limit the number of items kept (for example, keep only the top 3).
• Transform element maps values from a source collection to a target collection of a different type.
• You can reference an individual item only by looping; there is no direct index access in standard Flow (except the first item via formulas in certain contexts or by using Collection Sort with a limit of 1).
• Record collections are passed into Create Records, Update Records or Delete Records elements to perform a single bulk DML operation.
Exam insight: Questions that mention 'minimise the number of queries' or 'avoid governor limits' are frequently pointing you toward Collection Filter and Collection Sort instead of additional Get Records elements.
3. Loops
What it is: The Loop element iterates through every item in a collection, one at a time. For each iteration, the current item is available in a loop variable (automatically created as {!Loop_Name} in modern Flow Builder, referencing the current item). You configure the collection to loop through and the direction (first to last, or last to first).
Loop paths:
• For Each path – elements connected here run once for every item in the collection.
• After Last path – elements connected here run once after the final item has been processed. This is where your bulk Create/Update/Delete should go.
The bulkification pattern (memorise this):
1. Get Records (All records) – one query.
2. Decision – check the collection Is Null = False (records were found).
3. Loop through the collection.
4. Inside the loop: Decision and/or Assignment – modify fields on the loop variable or a new record variable, then Assignment (Add) the record to a separate record collection variable.
5. After Last: a single Update Records or Create Records using the collection variable – one DML statement.
Anti-patterns the exam loves:
• Placing Get Records, Create/Update/Delete Records, or Action elements inside a loop. Each iteration consumes a query or DML statement, so a collection of 200 records will breach the 100 SOQL / 150 DML limits.
• Modifying the loop variable and expecting the original collection to change. The loop variable is a copy; you must assign it into a new collection.
• Forgetting the null check before the loop. Looping over a null collection causes an error.
• Exceeding the 2,000 executed elements per interview limit. Every element executed in every iteration counts, so very large collections combined with many elements inside the loop can hit this limit even without DML.
4. Decisions
What it is: The Decision element evaluates conditions and routes the flow down one of several outcomes. It is the Flow equivalent of IF/ELSE IF/ELSE logic.
Configuration:
• Outcomes – you define one or more outcomes, each with its own conditions. Outcomes are evaluated top to bottom and the first outcome whose conditions are met is taken.
• Default Outcome – always present; taken when no other outcome's conditions are met. You can rename it (for example, 'Else').
• Condition Requirements – All Conditions Are Met (AND), Any Condition Is Met (OR), or Custom Condition Logic (for example, 1 AND (2 OR 3)).
• Operators – Equals, Does Not Equal, Is Null, Contains, Starts With, Greater Than, Is Changed (record-triggered flows), Was Set, Was Visited (screen flows) and more.
• In record-triggered flows you can set an outcome to execute only when the record is updated to meet the condition requirements, mimicking the old 'ISCHANGED' workflow behaviour.
Common uses:
• Null-checking Get Records output before using it.
• Branching inside a loop to decide which records to add to a collection.
• Comparing a count variable to a threshold.
• Checking {!$Record.Field} against {!$Record__Prior.Field} to detect changes in after-save flows.
Decision vs. Entry Conditions: For record-triggered flows, use entry conditions on the Start element to prevent the flow from running at all when it is not needed (better performance and fewer flow interviews). Use a Decision inside the flow when you need multiple branches of logic for records that do meet the entry criteria.
5. How It All Works Together: A Worked Example
Requirement: When an Account's Industry changes to 'Banking', update all of its open Opportunities to set a custom checkbox 'Priority Review' to true.
Design:
1. Record-Triggered Flow on Account, after save, entry condition: Industry Equals 'Banking' and run only when the record is updated to meet the condition.
2. Get Records: Opportunity, where AccountId Equals {!$Record.Id} AND IsClosed Equals False, store All records.
3. Decision: Outcome 'Found' – Get Records collection Is Null Equals False. Default outcome ends the flow.
4. Loop through the Opportunity collection.
5. Assignment (inside loop): set {!Loop_Opps.Priority_Review__c} Equals True; then Add {!Loop_Opps} to {!OppsToUpdate} collection.
6. Update Records (After Last path): update {!OppsToUpdate}.
This design uses exactly one SOQL query and one DML statement regardless of how many Opportunities exist.
6. Governor Limits and Performance Facts to Memorise
• 100 SOQL queries per synchronous transaction (Get Records consumes one each).
• 150 DML statements per transaction (each Create/Update/Delete Records element execution consumes one).
• 50,000 records retrieved by queries per transaction.
• 10,000 records processed by DML per transaction.
• 2,000 executed elements per flow interview.
• Record-triggered flows are automatically bulkified across records in the same transaction, but your design inside the flow still must avoid DML and queries in loops.
• Before-save record-triggered flows can use Get Records, Decisions, Assignments and Loops but cannot create, update or delete other records; they update only the triggering record via Assignment to {!$Record}. They are the fastest option for same-record field updates.
Exam Tips: Answering Questions on Get Records, Loops, Collections and Decisions in Flow
Tip 1 – Hunt for the anti-pattern. If a scenario describes a flow failing with 'Too many SOQL queries' or 'Too many DML statements', or failing only when records are imported via Data Loader, the answer almost always involves moving a Get Records or DML element out of the loop and using a collection variable with a single DML element after the loop.
Tip 2 – Null check before you loop. When a question asks what to add to prevent an error when no related records exist, the answer is a Decision checking whether the Get Records result Is Null. Remember: no records found = null, not an empty collection.
Tip 3 – 'Only the first record' vs 'All records'. If the requirement needs a single value (the most recent Case, the primary Contact), choose Get Records with a sort order and Only the first record. If the requirement mentions 'all related', 'each', or 'every', you need All records plus a Loop.
Tip 4 – Prefer in-memory operations. When you already have a collection and need a subset or ordering, pick Collection Filter or Collection Sort over a second Get Records. Questions emphasising efficiency or limits point here.
Tip 5 – Counting records. To check 'how many' related records exist, use Assignment with Equals Count on the collection, then a Decision on the number variable. Do not look for a 'Count' option in Get Records; it does not exist as a stored field in the standard element.
Tip 6 – Decision outcome order matters. Outcomes evaluate top to bottom and the first match wins. If a question describes records always taking the wrong path, suspect outcome ordering or a condition requirement set to 'Any' when it should be 'All'.
Tip 7 – Entry conditions vs Decisions. If the question asks how to reduce the number of flow interviews or improve performance of a record-triggered flow, choose entry conditions on the Start element. If it asks how to handle multiple different behaviours within one flow, choose a Decision.
Tip 8 – Detecting changes. For 'when field X changes' requirements in record-triggered flows, use the condition option to run only when the record is updated to meet conditions, or compare {!$Record.Field} with {!$Record__Prior.Field} in a Decision using the Is Changed operator.
Tip 9 – Loop variable is a copy. If a question states that records were not updated even though the flow ran without error, check whether the design updated the loop variable without adding it to a collection and running Update Records afterwards.
Tip 10 – Know the context. If Get Records returns fewer records than expected for some users, think about whether the flow runs in user context (respecting sharing and field-level security) versus system context. The fix is usually changing the flow's 'How to Run the Flow' setting, not adding more Get Records elements.
Tip 11 – Eliminate answers that use retired tools. Answers proposing Process Builder or Workflow Rules for new automation are distractors. Flow with Get Records, Loops, Collections and Decisions is the expected modern solution.
Tip 12 – Read for scale words. Phrases like 'thousands of records', 'nightly data load', 'integration' or 'bulk' signal that the correct answer must be bulk-safe: one query, collection assignment in the loop, one DML after the loop, and possibly a scheduled or asynchronous path.
Quick Reference Summary
• Get Records = query data (1 SOQL each); returns null when nothing found; never place inside a loop.
• Collection = list of records or values; build with Assignment (Add); filter and sort in memory; pass to one DML element.
• Loop = iterate a collection; For Each path for per-item logic; After Last path for bulk DML; loop variable is a copy.
• Decision = branching; first matching outcome wins; always has a default outcome; use for null checks, thresholds and change detection.
Master these four elements and their interplay with governor limits, and you will be well prepared for the Advanced Process Automation questions on the Salesforce Advanced Administrator exam.
Flow Builder is now the primary declarative automation tool in Salesforce. With Workflow Rules and Process Builder retired for new automation, the Advanced Administrator exam leans heavily on your ability to design efficient, scalable flows. The Advanced Process Automation section is one of the most heavily weighted areas of the exam, and almost every flow scenario question depends on four building blocks: Get Records (retrieving data), Collections (holding multiple records or values), Loops (iterating through collections) and Decisions (branching logic). If you understand how these elements interact, and especially how they relate to governor limits and bulkification, you can answer the majority of flow design questions with confidence. Expect questions that describe a business requirement and ask which element or combination of elements you should use, or that describe a failing flow and ask you to diagnose the design error.
1. Get Records
What it is: Get Records is a data element that queries the Salesforce database and returns one or more records that match your filter criteria. Behind the scenes, every Get Records element consumes one SOQL query from the transaction's governor limit (100 SOQL queries per synchronous transaction).
Key configuration options:
• Object – the object to query (for example, Contact).
• Filter Conditions – one or more conditions combined with AND, OR or custom logic. You can filter by field values, variables, formulas or the triggering record's fields (such as {!$Record.AccountId}).
• Sort Order – ascending or descending by a chosen field. Sorting matters when you select only the first record (for example, the most recent Opportunity).
• How Many Records to Store – Only the first record stores a single record variable; All records stores a record collection variable.
• How to Store Record Data – Automatically store all fields (recommended for simplicity), Choose fields and let Salesforce store them, or Choose fields and assign variables (advanced) where you map fields into existing variables.
• When no records are returned – by default the output variable is set to null. In the advanced manual-assignment mode you can choose to leave existing variable values unchanged.
Critical behaviour to remember:
• When Get Records finds nothing, the output variable (single record or collection) is null. You should test for this with a Decision using the Is Null = True operator before looping or referencing a field, otherwise the flow will throw an unhandled fault.
• Get Records returns records that the running user can see when the flow runs in user context; it returns all records when the flow runs in system context without sharing. Flow context is an exam favourite.
• A Get Records element placed inside a Loop executes once per iteration – this is the classic anti-pattern that leads to 'Too many SOQL queries: 101' errors.
2. Collections
What they are: A collection variable holds multiple values of the same data type. The most common types are record collection variables (a list of Account records, for example), and text, number, date or picklist collections. Get Records with 'All records' automatically produces a record collection variable.
Working with collections:
• Assignment element with the Add operator appends a record or value to a collection. This is how you build a list of records to update or create in bulk.
• Assignment element with Equals Count stores the number of items in a collection into a number variable – useful for Decisions such as 'Does the Account have more than 5 open Cases?'.
• Collection Filter element filters an existing collection in memory without a new SOQL query. Use it when you already have the records and need a subset.
• Collection Sort element sorts an existing collection and can limit the number of items kept (for example, keep only the top 3).
• Transform element maps values from a source collection to a target collection of a different type.
• You can reference an individual item only by looping; there is no direct index access in standard Flow (except the first item via formulas in certain contexts or by using Collection Sort with a limit of 1).
• Record collections are passed into Create Records, Update Records or Delete Records elements to perform a single bulk DML operation.
Exam insight: Questions that mention 'minimise the number of queries' or 'avoid governor limits' are frequently pointing you toward Collection Filter and Collection Sort instead of additional Get Records elements.
3. Loops
What it is: The Loop element iterates through every item in a collection, one at a time. For each iteration, the current item is available in a loop variable (automatically created as {!Loop_Name} in modern Flow Builder, referencing the current item). You configure the collection to loop through and the direction (first to last, or last to first).
Loop paths:
• For Each path – elements connected here run once for every item in the collection.
• After Last path – elements connected here run once after the final item has been processed. This is where your bulk Create/Update/Delete should go.
The bulkification pattern (memorise this):
1. Get Records (All records) – one query.
2. Decision – check the collection Is Null = False (records were found).
3. Loop through the collection.
4. Inside the loop: Decision and/or Assignment – modify fields on the loop variable or a new record variable, then Assignment (Add) the record to a separate record collection variable.
5. After Last: a single Update Records or Create Records using the collection variable – one DML statement.
Anti-patterns the exam loves:
• Placing Get Records, Create/Update/Delete Records, or Action elements inside a loop. Each iteration consumes a query or DML statement, so a collection of 200 records will breach the 100 SOQL / 150 DML limits.
• Modifying the loop variable and expecting the original collection to change. The loop variable is a copy; you must assign it into a new collection.
• Forgetting the null check before the loop. Looping over a null collection causes an error.
• Exceeding the 2,000 executed elements per interview limit. Every element executed in every iteration counts, so very large collections combined with many elements inside the loop can hit this limit even without DML.
4. Decisions
What it is: The Decision element evaluates conditions and routes the flow down one of several outcomes. It is the Flow equivalent of IF/ELSE IF/ELSE logic.
Configuration:
• Outcomes – you define one or more outcomes, each with its own conditions. Outcomes are evaluated top to bottom and the first outcome whose conditions are met is taken.
• Default Outcome – always present; taken when no other outcome's conditions are met. You can rename it (for example, 'Else').
• Condition Requirements – All Conditions Are Met (AND), Any Condition Is Met (OR), or Custom Condition Logic (for example, 1 AND (2 OR 3)).
• Operators – Equals, Does Not Equal, Is Null, Contains, Starts With, Greater Than, Is Changed (record-triggered flows), Was Set, Was Visited (screen flows) and more.
• In record-triggered flows you can set an outcome to execute only when the record is updated to meet the condition requirements, mimicking the old 'ISCHANGED' workflow behaviour.
Common uses:
• Null-checking Get Records output before using it.
• Branching inside a loop to decide which records to add to a collection.
• Comparing a count variable to a threshold.
• Checking {!$Record.Field} against {!$Record__Prior.Field} to detect changes in after-save flows.
Decision vs. Entry Conditions: For record-triggered flows, use entry conditions on the Start element to prevent the flow from running at all when it is not needed (better performance and fewer flow interviews). Use a Decision inside the flow when you need multiple branches of logic for records that do meet the entry criteria.
5. How It All Works Together: A Worked Example
Requirement: When an Account's Industry changes to 'Banking', update all of its open Opportunities to set a custom checkbox 'Priority Review' to true.
Design:
1. Record-Triggered Flow on Account, after save, entry condition: Industry Equals 'Banking' and run only when the record is updated to meet the condition.
2. Get Records: Opportunity, where AccountId Equals {!$Record.Id} AND IsClosed Equals False, store All records.
3. Decision: Outcome 'Found' – Get Records collection Is Null Equals False. Default outcome ends the flow.
4. Loop through the Opportunity collection.
5. Assignment (inside loop): set {!Loop_Opps.Priority_Review__c} Equals True; then Add {!Loop_Opps} to {!OppsToUpdate} collection.
6. Update Records (After Last path): update {!OppsToUpdate}.
This design uses exactly one SOQL query and one DML statement regardless of how many Opportunities exist.
6. Governor Limits and Performance Facts to Memorise
• 100 SOQL queries per synchronous transaction (Get Records consumes one each).
• 150 DML statements per transaction (each Create/Update/Delete Records element execution consumes one).
• 50,000 records retrieved by queries per transaction.
• 10,000 records processed by DML per transaction.
• 2,000 executed elements per flow interview.
• Record-triggered flows are automatically bulkified across records in the same transaction, but your design inside the flow still must avoid DML and queries in loops.
• Before-save record-triggered flows can use Get Records, Decisions, Assignments and Loops but cannot create, update or delete other records; they update only the triggering record via Assignment to {!$Record}. They are the fastest option for same-record field updates.
Exam Tips: Answering Questions on Get Records, Loops, Collections and Decisions in Flow
Tip 1 – Hunt for the anti-pattern. If a scenario describes a flow failing with 'Too many SOQL queries' or 'Too many DML statements', or failing only when records are imported via Data Loader, the answer almost always involves moving a Get Records or DML element out of the loop and using a collection variable with a single DML element after the loop.
Tip 2 – Null check before you loop. When a question asks what to add to prevent an error when no related records exist, the answer is a Decision checking whether the Get Records result Is Null. Remember: no records found = null, not an empty collection.
Tip 3 – 'Only the first record' vs 'All records'. If the requirement needs a single value (the most recent Case, the primary Contact), choose Get Records with a sort order and Only the first record. If the requirement mentions 'all related', 'each', or 'every', you need All records plus a Loop.
Tip 4 – Prefer in-memory operations. When you already have a collection and need a subset or ordering, pick Collection Filter or Collection Sort over a second Get Records. Questions emphasising efficiency or limits point here.
Tip 5 – Counting records. To check 'how many' related records exist, use Assignment with Equals Count on the collection, then a Decision on the number variable. Do not look for a 'Count' option in Get Records; it does not exist as a stored field in the standard element.
Tip 6 – Decision outcome order matters. Outcomes evaluate top to bottom and the first match wins. If a question describes records always taking the wrong path, suspect outcome ordering or a condition requirement set to 'Any' when it should be 'All'.
Tip 7 – Entry conditions vs Decisions. If the question asks how to reduce the number of flow interviews or improve performance of a record-triggered flow, choose entry conditions on the Start element. If it asks how to handle multiple different behaviours within one flow, choose a Decision.
Tip 8 – Detecting changes. For 'when field X changes' requirements in record-triggered flows, use the condition option to run only when the record is updated to meet conditions, or compare {!$Record.Field} with {!$Record__Prior.Field} in a Decision using the Is Changed operator.
Tip 9 – Loop variable is a copy. If a question states that records were not updated even though the flow ran without error, check whether the design updated the loop variable without adding it to a collection and running Update Records afterwards.
Tip 10 – Know the context. If Get Records returns fewer records than expected for some users, think about whether the flow runs in user context (respecting sharing and field-level security) versus system context. The fix is usually changing the flow's 'How to Run the Flow' setting, not adding more Get Records elements.
Tip 11 – Eliminate answers that use retired tools. Answers proposing Process Builder or Workflow Rules for new automation are distractors. Flow with Get Records, Loops, Collections and Decisions is the expected modern solution.
Tip 12 – Read for scale words. Phrases like 'thousands of records', 'nightly data load', 'integration' or 'bulk' signal that the correct answer must be bulk-safe: one query, collection assignment in the loop, one DML after the loop, and possibly a scheduled or asynchronous path.
Quick Reference Summary
• Get Records = query data (1 SOQL each); returns null when nothing found; never place inside a loop.
• Collection = list of records or values; build with Assignment (Add); filter and sort in memory; pass to one DML element.
• Loop = iterate a collection; For Each path for per-item logic; After Last path for bulk DML; loop variable is a copy.
• Decision = branching; first matching outcome wins; always has a default outcome; use for null checks, thresholds and change detection.
Master these four elements and their interplay with governor limits, and you will be well prepared for the Advanced Process Automation questions on the Salesforce Advanced Administrator exam.
Test mode:
Admin II - Get Records, Loops, Collections and Decisions in Flow Example Questions
Test your knowledge of Get Records, Loops, Collections and Decisions in Flow
Question 1
How does a Flow Decision element choose which path to follow when the conditions of more than one outcome evaluate to true at runtime?
Question 2
At Cloud Kicks, when an Account's Status changes to Inactive, every related Contact must have the Email Opt Out checkbox selected. The administrator drafted an after-save flow on Account. It uses Get Records, a Loop, an Assignment, and a collection variable that feeds one final Update Records element. A reviewer wants the design with the fewest flow elements that still updates all related contacts in bulk-safe fashion. What should the administrator build?
Question 3
Universal Containers has an after-save record-triggered flow on Opportunity. When an opportunity is marked Closed Won, a Get Records element retrieves its open Tasks. A Loop then iterates through them, and an Update Records element inside the loop closes each task. Single edits work, but a nightly data load of several hundred closed opportunities fails with a governor limit error. What should the administrator change to resolve the failure?
Unlock Premium Access
Salesforce Certified Platform Administrator II
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 2973 Superior-grade Salesforce Certified Platform Administrator II practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- Admin II: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Get Records, Loops, Collections and Decisions in Flow questions
30 questions (total)
Other Process Automation concepts
Approval Processes: Steps, Approvers and ActionsAutolaunched Flows and SubflowsBefore-Save Versus After-Save Record-Triggered FlowsBulkification and Governor Limits in FlowsChoosing the Right Declarative Automation ToolDebugging Flows and Flow Error EmailsEmail Alerts and Outbound MessagesEntry Conditions and Run-When-Updated CriteriaFault Paths and Error Handling in FlowsFlow Trigger Explorer and Trigger OrderFormula Fields and Validation Rules in Automation DesignMigrating Workflow Rules and Process Builder to FlowMulti-Step and Parallel ApprovalsOrder of ExecutionPlatform Event-Triggered FlowsScheduled Paths and Schedule-Triggered FlowsScreen FlowsTroubleshooting Approval Processes and Record LockingTroubleshooting Automation with Debug Logs