All practice questions

1784 questions

All types1,784 Multiple choice918 Multiple select587 Matching142 Ordering137

A Salesforce Administrator is designing a Flow on the Service Contract object to update all child Entitlement records when a contract is renewed. To ensure the automation adheres to Salesforce bulkification standards and avoids governor limits, in what sequence should the Flow elements be executed?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of elements is: 1) Retrieve related Entitlement records using Get Records, 2) Loop through the record collection, 3) Update field values on the current loop item with an Assignment element, 4) Add the updated loop item to a secondary Record Collection variable with an Assignment element, and 5) Execute an Update Records element outside the loop.

The correct sequence starts by retrieving all child records with a single Get Records element, looping through the collection to modify field values in memory, staging each modified item into a secondary collection, and finally performing a single Update Records DML operation outside the loop.

Step-by-Step Solution

Query related records.

A collection variable containing all related Entitlement records is created.

Data must be fetched before it can be iterated on or modified.

Begin collection iteration.

The flow begins iterating through each individual record item in the collection.

Looping enables individual field modifications for items in a collection.

Assign updated field values to current loop item.

The in-memory record item reflects the new status value.

Field changes must be defined in memory before saving to the record collection.

Add modified item to output collection.

The secondary collection now contains the updated record instance.

Collecting modified records ensures they can be updated in a single DML operation.

Perform bulk update outside loop.

All modified records are saved to the database in a single transaction.

Executing DML outside the loop prevents hitting SOQL/DML governor limits.

Key Concept

Flow Bulkification and Element Sequencing

Estimated Time:1m 30s

Question 1542Question →

A Salesforce Administrator at a regional commercial bank is configuring an Opportunity report for commercial loan applications. Management requires the report to categorize open loans into Low, Medium, and High risk tiers based on ranges from a numerical Risk Score field. Additionally, management wants to apply complex filter criteria that evaluate multiple stage conditions using custom Boolean grouping. Which two actions should the administrator take to fulfill these requirements using standard report capabilities? (Select TWO answers.)

Select all that apply

Create a Bucket Field on the numerical Risk Score field to segment loan records into Low, Medium, and High risk value ranges directly within the report.

Add Filter Logic to customize the Boolean evaluation order using parentheses, such as (1 AND 2) OR 3, across the report field filters.

Create a Summary Formula Field to categorize individual loan application records into risk tiers before applying report filters.

Create a Roll-Up Summary Field on the User object to aggregate loan application totals and filter out inactive loan officers.

Show answer & explanation

Answer: Create a Bucket Field on the numerical Risk Score field to segment loan records into Low, Medium, and High risk value ranges directly within the report.; Add Filter Logic to customize the Boolean evaluation order using parentheses, such as (1 AND 2) OR 3, across the report field filters.

Answer

The administrator should create a Bucket Field on the numerical Risk Score field to define the Low, Medium, and High risk ranges, and use Filter Logic with parentheses to control the Boolean evaluation order of field filter criteria.

Creating a bucket field on a numerical field allows report-level grouping into designated ranges without custom field creation. Applying filter logic allows precise Boolean grouping of multiple report filter conditions using parentheses.

Step-by-Step Solution

Identify the requirement for categorizing numeric values into discrete tiers within the report.

Determine that a Bucket Field on the numerical Risk Score field allows defining ranges (e.g., 0-300 Low, 301-600 Medium, 601-900 High) without modifying object schema.

Bucket fields provide inline record categorizations for Numeric, Picklist, and Text fields in reports.

Identify the requirement for complex Boolean condition evaluation.

Add Filter Logic to specify custom operators and grouping parentheses like (1 AND 2) OR 3.

Standard report field filters evaluate sequentially as AND unless explicit Filter Logic is configured.

Key Concept

Report Bucketing and Filter Logic

Estimated Time:1m 30s

Question 1543Question →

A System Administrator at a renewable energy company needs to configure immediate automated actions using Workflow Rules whenever a High-Priority Maintenance Request record is created. Which automated actions can be configured directly as native Workflow Actions? (Select TWO answers.)

Select all that apply

Sending an Outbound Message to a designated external SOAP endpoint

Creating a Task assigned to a specific user or role

Posting a custom notification message directly to the record Chatter feed

Executing an Apex class method directly without invoking a Flow

Show answer & explanation

Answer: Sending an Outbound Message to a designated external SOAP endpoint; Creating a Task assigned to a specific user or role

Answer

The correct automated actions that can be configured directly as Workflow Actions are sending an Outbound Message to an external SOAP endpoint and creating a Task assigned to a specific user.

Salesforce Workflow Rules natively support exactly four types of automated actions: Field Updates, Email Alerts, Tasks, and Outbound Messages. Therefore, sending an Outbound Message to a SOAP endpoint and creating a Task assigned to a user are both valid immediate workflow actions.

Step-by-Step Solution

Identify the four native actions available in Salesforce Workflow Rules.

The supported workflow actions are Field Updates, Email Alerts, Tasks, and Outbound Messages.

Salesforce restricts classic Workflow Rules to these four specific declarative action types.

Evaluate each option against the supported workflow actions.

Outbound Messages and Tasks are native workflow actions, whereas Chatter posts and direct Apex execution are not supported in Workflow Rules.

Complex actions such as posting to Chatter feeds or invoking Apex require modern automation tools like Flow Builder.

Key Concept

Supported native Workflow Actions in Salesforce classic Workflow Rules

Estimated Time:1m 30s

Question 1544Question →

A Salesforce Administrator at an event management software company is creating an Opportunity report to highlight key deals for executive review. Management requires the report to display Opportunities that meet all of the following conditions:

- The Stage is either Closed Won or Proposal/Price Quote.
- The Amount is greater than $50,000.
- The Type is either Existing Customer - Upgrade or Existing Customer - Replacement.

The administrator creates the following individual field filters on the report:

1. Stage equals Closed Won
2. Stage equals Proposal/Price Quote
3. Amount greater than 50000
4. Type equals Existing Customer - Upgrade
5. Type equals Existing Customer - Replacement

Which filter logic configuration should the administrator apply to meet the business requirements?

(1 OR 2) AND 3 AND (4 OR 5)

1 OR 2 AND 3 AND 4 OR 5

(1 AND 2) OR 3 OR (4 AND 5)

(1 OR 2 OR 3) AND (4 OR 5)

Show answer & explanation

Answer: (1 OR 2) AND 3 AND (4 OR 5)

Answer

The custom filter logic must be configured as (1 OR 2) AND 3 AND (4 OR 5).

The expression (1 OR 2) AND 3 AND (4 OR 5) uses explicit parentheses to create three distinct criteria groups. The Stage criteria (filters 1 and 2) are evaluated as a logical unit where either stage is acceptable. Similarly, the Type criteria (filters 4 and 5) are evaluated as a logical unit. The AND operators mandate that the record must simultaneously satisfy the Stage group, the Amount threshold (filter 3), and the Type group.

Step-by-Step Solution

Analyze the Stage requirements

Since an Opportunity Stage can be either Closed Won OR Proposal/Price Quote, group filters 1 and 2 as (1 OR 2).

Parentheses ensure that meeting either Stage condition satisfies the Stage criteria group.

Analyze the Type requirements

Since the Opportunity Type can be either Existing Customer - Upgrade OR Existing Customer - Replacement, group filters 4 and 5 as (4 OR 5).

Parentheses ensure that meeting either Type condition satisfies the Type criteria group.

Combine all three required conditions with AND logic

Join the grouped Stage logic, the Amount filter (filter 3), and the grouped Type logic together: (1 OR 2) AND 3 AND (4 OR 5).

All three criteria groups (Stage, Amount, and Type) must be met simultaneously for a record to appear in the report.

Key Concept

Salesforce Report Custom Filter Logic and Boolean Parenthesization

Question 1545Question →

An administrator is designing an autolaunched flow that processes a large collection of Opportunity records associated with an Account to aggregate financial metrics and update parent fields. Which two data manipulation and resource design practices should the administrator implement to ensure the flow executes within Salesforce governor limits? (Select 2 options)

Select all that apply

Filter records directly within the Get Records element query criteria rather than retrieving all records and filtering them downstream using a Decision element.

Use an Assignment element inside the loop to accumulate values into a variable, then perform a single Update Records element outside the loop.

Place an Update Records element inside the Loop element to save changes to each Opportunity record individually during each iteration.

Place a Get Records element inside the Loop element to re-query related line items for each Opportunity on every loop iteration.

Show answer & explanation

Answer: Filter records directly within the Get Records element query criteria rather than retrieving all records and filtering them downstream using a Decision element.; Use an Assignment element inside the loop to accumulate values into a variable, then perform a single Update Records element outside the loop.

Answer

The correct practices are to filter records directly within the Get Records element query criteria and to accumulate values in a variable using an Assignment element inside the loop while placing the Update Records element outside the loop.

Filtering criteria directly inside the Get Records element reduces database overhead by retrieving only necessary records. In addition, using Assignment elements inside the loop to build in-memory updates or collections and executing database operations outside the loop ensures the flow is bulkified and compliant with governor limits.

Step-by-Step Solution

Evaluate record querying best practices.

Filtering records directly in the Get Records element minimizes SOQL output and memory usage.

Retrieving unfiltered records and evaluating them in memory consumes unnecessary resources and may hit limits.

Evaluate loop iterations and DML positioning.

Placing Assignment elements inside the loop to update record variables in memory allows bulkified DML outside the loop.

Executing DML elements inside a loop causes governor limit exceptions.

Key Concept

Flow Bulkification and Resource Management

Question 1546Question →

An administrator at CloudScale Systems creates and activates a custom Matching Rule on the Account object using exact match logic on Account Name and Billing City. However, sales representatives are still able to create duplicate accounts without seeing any warning prompts or blocked attempts, and no duplicates appear in duplicate record reports. What step did the administrator forget to perform to enforce duplicate handling?

The administrator must create and activate a Duplicate Rule that references the custom Matching Rule to define enforcement actions like alert, block, or report.

The administrator must assign the active Matching Rule directly to user profiles under Object Manager field permissions.

The administrator must deploy Apex trigger logic to invoke matching rules, as matching rules only execute automated batch jobs by default.

The administrator must replace the custom Matching Rule with a standard Account Matching Rule, as custom matching rules only operate on custom objects.

Show answer & explanation

Answer: The administrator must create and activate a Duplicate Rule that references the custom Matching Rule to define enforcement actions like alert, block, or report.

Answer

The administrator must create and activate a Duplicate Rule that references the custom Matching Rule to define enforcement actions like alert, block, or report.

Matching rules only specify the comparison criteria used to identify duplicate records (e.g., exact match on Account Name and Billing City). To actually prevent duplicates or alert users, an administrator must configure and activate a Duplicate Rule that references that Matching Rule and specifies the desired action, such as alerting the user, blocking the save operation, or generating duplicate record reports.

Step-by-Step Solution

Distinguish between the purpose of a Matching Rule and a Duplicate Rule.

Matching rules define matching criteria (which fields to compare and match logic), whereas duplicate rules dictate the timing and enforcement action (such as Alert, Block, or Report).

Creating and activating a matching rule alone does not execute any user-facing or backend actions.

Identify the missing setup requirement in the administrator's workflow.

The administrator activated the matching rule but omitted creating and activating a corresponding Duplicate Rule.

Without an active duplicate rule that references the matching rule, Salesforce cannot prompt users, prevent duplicate creations, or log duplicate records.

Key Concept

Matching rules define how duplicate records are identified, whereas duplicate rules define what happens when duplicates are detected.

Question 1547Question →

An organization uses a custom object named Equipment_Maintenance__c. An administrator configures the following features on the object:

1. A Before-Save Record-Triggered Flow that calculates and sets the Total_Cost__c field to equal Parts_Cost__c + Labor_Cost__c.
2. A Custom Validation Rule with the formula Total_Cost__c > 5000 that displays an error to prevent saving high-cost maintenance records without manager approval.
3. An After-Save Record-Triggered Flow that creates a follow-up task for the facility manager.
4. A Workflow Rule that sends an email notification to the maintenance supervisor.

A technician updates an existing record, changing Parts_Cost__c to $3,000 and Labor_Cost__c to$ 3,000 (making the calculated total $6,000), while leaving Total_Cost__c blank on the page layout.

Which statement accurately describes how Salesforce processes this save operation according to the order of execution?

The Before-Save Record-Triggered Flow executes first to set Total_Cost__c to $6,000; then the Custom Validation Rule evaluates the updated Total_Cost__c value and blocks the record from saving.

The Custom Validation Rule evaluates Total_Cost__c using the blank value first and passes; then the Before-Save Record-Triggered Flow populates Total_Cost__c with $6,000.

The record is saved to the database first; then the Custom Validation Rule and Before-Save Record-Triggered Flow run concurrently before Workflow Rules execute.

The Workflow Rule evaluates Total_Cost__c before the Before-Save Record-Triggered Flow populates the calculated field value.

Show answer & explanation

Answer: The Before-Save Record-Triggered Flow executes first to set Total_Cost__c to $6,000; then the Custom Validation Rule evaluates the updated Total_Cost__c value and blocks the record from saving.

Answer

The Before-Save Record-Triggered Flow executes first to set Total_Cost__c to $6,000; then the Custom Validation Rule evaluates the updated Total_Cost__c value and blocks the record from saving.

In the Salesforce Order of Execution, Before-Save Record-Triggered Flows execute very early (step 4), prior to Apex before triggers and custom validation rules (step 6). As a result, the flow calculates and updates the field value to

6,000 first. When the custom validation rule executes next, it reads the updated value of

6,000, satisfies the error condition (

6,000 >

5,000), and blocks the save operation.

Step-by-Step Solution

Analyze the incoming request data

Parts_Cost__c is updated to

3,000 and Labor_Cost__c to

3,000.

The system loads the new field values from the user input into the record memory.

Evaluate early automation steps in the Salesforce Order of Execution

Before-Save Record-Triggered Flows execute before custom validation rules.

Salesforce order of execution explicitly runs Before-Save Flows at step 4, updating Total_Cost__c to $6,000.

Evaluate validation rules

Custom Validation Rules execute at step 6, testing the formula Total_Cost__c > 5000.

Since Total_Cost__c was set to

6,000 by the Before-Save Flow,

6,000 > $5,000 evaluates to TRUE, triggering the validation error and stopping the transaction.

Key Concept

Salesforce Order of Execution relative timing between Before-Save Record-Triggered Flows and Custom Validation Rules.

Estimated Time:2m 0s

Question 1548Question →

Universal Containers requires an automated process that updates all open Case records associated with an Account whenever an Opportunity for that Account is set to 'Closed Won'. Which Flow Builder logic pattern should be implemented to update these related records while strictly adhering to governor limit best practices?

Query related Case records before entering a Loop, use an Assignment element inside the loop to modify field values into a record collection variable, and invoke a single Update Records element after the loop finishes.

Query related Case records before entering a Loop, but execute an Update Records element inside the loop on each iteration to commit changes immediately.

Configure a Fast Field Update (Before-Save) record-triggered flow on the Opportunity object to update the child Case records before the triggering record is saved.

Create a roll-up summary field on the Account object that calculates open Cases and triggers an automatic update to child Case records when the Opportunity stage changes.

Show answer & explanation

Answer: Query related Case records before entering a Loop, use an Assignment element inside the loop to modify field values into a record collection variable, and invoke a single Update Records element after the loop finishes.

Answer

To process multiple records efficiently without exceeding governor limits, data retrieval (Get Records) and data persistence (Update Records) must occur outside of any Loop element. Using an Assignment element inside the loop to stage changes into a record collection variable allows all updates to be executed in a single DML operation after loop execution completes.

Step-by-Step Solution

Identify the automation requirement and scope.

The requirement involves updating related child records (Case) based on changes to a parent/sibling record (Opportunity).

An After-Save record-triggered flow or autolaunched flow is required because related records are being updated.

Evaluate Flow Builder logic for bulkification.

SOQL queries (Get Records) and DML statements (Update Records, Create Records, Delete Records) must never reside inside a Loop element.

Iterating over records and executing DML operations within a loop exhausts the maximum limit of 150 DML statements per transaction.

Select the correct sequence of Flow elements.

Use Get Records outside the loop → Loop through items → Use Assignment element to populate values into a record collection variable → Use Update Records outside the loop on the record collection variable.

This pattern ensures exactly one DML operation is performed regardless of how many records are processed.

Key Concept

Flow Bulkification and Governor Limits

Estimated Time:1m 30s

Question 1549Question →

When a high-value Opportunity record enters the 'Negotiation/Review' stage, sales management requires automated operations to streamline internal governance. Which TWO actions can be configured directly as built-in immediate actions within Process Builder without writing custom Apex code or calling a Flow? Select TWO choices.

Select all that apply

Submit the triggering Opportunity record automatically into an active approval process.

Send a native Custom Notification to the Opportunity owner and designated sales leaders.

Hard delete related inactive Opportunity Line Item records to clean up unused data.

Directly configure and transmit a SOAP Outbound Message to an external billing endpoint.

Show answer & explanation

Answer: Submit the triggering Opportunity record automatically into an active approval process.; Send a native Custom Notification to the Opportunity owner and designated sales leaders.

Answer

Submitting the record for approval and sending a custom notification are both supported natively as direct immediate actions in Process Builder.

Submitting a record into an active approval process and sending a custom notification are both standard, natively supported action types available within Process Builder's immediate action framework. They execute declaratively without needing Apex classes or Flow elements.

Step-by-Step Solution

Analyze Process Builder's standard immediate action type repository.

Identify supported declarative action types, which include Apex, Create a Record, Email Alerts, Flows, Post to Chatter, Processes, Quick Actions, Quip, Send Custom Notification, Submit for Approval, and Update Records.

Process Builder provides specific declarative capabilities designed to eliminate the need for custom code or external automation tools.

Evaluate the requirement for submitting records for approval.

'Submit for Approval' is confirmed as a standard, native immediate action type in Process Builder.

It allows administrators to route records directly to an approval process when criteria are met.

Evaluate the notification requirement.

'Send Custom Notification' is confirmed as a standard, native immediate action type in Process Builder.

It allows dispatches of real-time push alerts to user devices via pre-configured Custom Notification definitions.

Assess platform constraints regarding record deletion and outbound messaging.

Process Builder lacks native 'Delete Record' and 'Outbound Message' action categories.

Deleting records requires Flow or Apex, while sending Outbound Messages directly requires Workflow Rules, Apex, or External Services.

Key Concept

Process Builder Standard Action Types vs. Platform Limitations

Question 1550Question →

A Salesforce administrator at Meridian Global Consulting is tasked with setting up duplicate detection for custom Lead records. What is the correct sequence of administrative steps required to build, configure, and activate this duplicate management process?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct administrative sequence is: 1) Create a custom Matching Rule specifying comparison criteria, 2) Activate the custom Matching Rule, 3) Create a new Duplicate Rule and select the activated Matching Rule, 4) Configure the enforcement actions (Alert, Report, or Block), and 5) Activate the Duplicate Rule.

The correct order requires creating the matching rule criteria first, activating that matching rule so it becomes available, referencing it within a new duplicate rule, specifying the operational actions (Block/Allow/Report), and finally activating the duplicate rule to enforce the setup.

Step-by-Step Solution

Create the custom Matching Rule.

Establishes the specific algorithm and field-level criteria used to compare records.

Matching logic must exist before a duplicate rule can evaluate incoming record data.

Activate the Matching Rule.

Makes the matching rule active and selectable within the setup framework.

Salesforce duplicate rules cannot reference or process inactive matching rules.

Create the Duplicate Rule and associate the active Matching Rule.

Binds the matching logic to the target object and record operation triggers.

Duplicate rules define the execution context and scope for matching criteria.

Set the operational actions (Block or Allow with Alert/Report).

Defines user experience and data governance behavior when duplicates are flagged.

Enforcement settings determine whether record saving is stopped or merely logged.

Activate the Duplicate Rule.

Enforces duplicate detection in real time for end users.

Duplicate rules remain ineffective until explicitly activated.

Key Concept

Duplicate management setup requires creating and activating matching logic first, followed by building the duplicate rule, setting its execution actions, and activating the duplicate rule.

Question 1551Question →

A Salesforce administrator at a commercial real estate agency needs to automate a field update process on a custom object named Property Listing. When a Property Listing record's Status field is changed to 'Under Contract', two fields on that same Property Listing record must be automatically updated: the Pending Date field must be set to the current date, and the Escrow Status field must be updated to 'Pending Deposit'. The solution must be declarative, optimized for maximum performance, and avoid unnecessary database writes or re-triggering the Salesforce order of execution. Which automation tool configuration should the administrator select to meet these requirements?

A Record-Triggered Flow configured for Fast Field Updates (before-save trigger)

A Record-Triggered Flow configured for Actions and Related Records (after-save trigger) with an Update Records element

A Roll-Up Summary field configured on the Property Listing object to evaluate and set the pending status

An Autolaunched Flow called iteratively inside a loop from Process Builder to update the record fields

Show answer & explanation

Answer: A Record-Triggered Flow configured for Fast Field Updates (before-save trigger)

Answer

A Record-Triggered Flow configured for Fast Field Updates (before-save trigger) is the optimal choice for updating fields on the record that initiated the automation.

The correct choice is the Record-Triggered Flow configured for Fast Field Updates (before-save trigger). When automation only needs to modify fields on the record that initiated the event, Salesforce best practice dictates using a before-save record-triggered flow. Because the updates happen in memory before the record is written to the database, no additional DML statement is required, minimizing system overhead and preventing re-triggering of the order of execution.

Step-by-Step Solution

Identify the target record being updated

The requirements specify updating fields on the exact same Property Listing record that triggered the automation.

Determining whether the updates apply to the triggering record or related records dictates the trigger timing.

Evaluate performance and execution timing criteria

Fast Field Updates (before-save) run up to 10 times faster than after-save updates because values are set in memory before committing to the database.

Before-save flows prevent redundant DML operations and avoid re-entering the Salesforce order of execution.

Select the appropriate declarative automation tool

Configure a Record-Triggered Flow using the 'Fast Field Updates' optimization setting.

Record-Triggered Flow is Salesforce's primary declarative automation tool, and Fast Field Updates is explicitly optimized for same-record modifications.

Key Concept

Declarative Automation Selection: Before-Save vs. After-Save Record-Triggered Flows

Question 1552Question →

When a customer support agent updates a Case record, several automated processes and validation mechanisms are triggered. Place the following automation events in the exact sequence in which Salesforce processes them during the record save operation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of execution is: 1) Before-Save Record-Triggered Flows, 2) Custom Validation Rules, 3) Case Assignment Rules, 4) After-Save Record-Triggered Flows, 5) Parent record Roll-Up Summary updates.

Salesforce processes save operations in a strict sequence: Before-Save Record-Triggered Flows execute first, followed by Custom Validation Rules. After the initial database save, Case Assignment Rules execute, followed by After-Save Record-Triggered Flows. Finally, parent record Roll-Up Summary fields are recalculated near the end of the transaction.

Step-by-Step Solution

Evaluate pre-save automation events

Before-Save Record-Triggered Flows execute first to modify record fields before database operations or validation.

Salesforce prioritizes fast before-save flow evaluations prior to validation and Apex execution.

Evaluate data quality enforcement

Custom Validation Rules run next to verify data integrity against any changes made by the user or before-save flows.

Custom validation ensures invalid data is rejected before saving changes into the database layer.

Evaluate initial post-save rules

Case Assignment Rules evaluate after the record is saved to the database but before after-save flow logic runs.

System assignment rules run immediately after initial database write and after-trigger processing.

Evaluate post-save flow automation

After-Save Record-Triggered Flows execute to perform actions like creating related records or sending notifications.

After-save flows execute after workflow and assignment rules complete.

Evaluate parent object calculations

Roll-Up Summary fields on parent records recalculate.

Parent roll-up summaries are updated after child record automation and deferred operations finish.

Key Concept

Salesforce Order of Execution during record save operations

Question 1553Question →

An administrator is designing an after-save record-triggered flow on the Account object to update all related open Work Orders when an Account is marked as inactive. To ensure optimal performance and avoid reaching SOQL and DML governor limits, which two design practices should the administrator follow? (Select 2 answers.)

Select all that apply

Execute a single Get Records element outside of any loop to retrieve all open Work Orders into a record collection variable.

Place an Update Records element inside the Loop element to immediately save changes for each individual Work Order.

Use an Assignment element within the loop to update record values in a collection, then execute a single Update Records element after the loop completes.

Create a Roll-Up Summary field on the Account object to perform the field updates on child records over a lookup relationship.

Show answer & explanation

Answer: Execute a single Get Records element outside of any loop to retrieve all open Work Orders into a record collection variable.; Use an Assignment element within the loop to update record values in a collection, then execute a single Update Records element after the loop completes.

Answer

The administrator should execute a single Get Records element outside of any loop to retrieve open Work Orders into a collection variable, and use an Assignment element inside the loop to accumulate changes in a collection before calling a single Update Records element after the loop.

To design bulkified flows that respect Salesforce governor limits, data retrieval (Get Records) and data manipulation (Update Records) elements must be placed outside of loops. The flow should fetch all target records in a single SOQL query, iterate over the collection to assign new field values in memory, and update the modified collection using a single DML operation after the loop completes.

Step-by-Step Solution

Retrieve related records efficiently

Obtained all target child records using a single Get Records element prior to loop entry.

Issuing data retrieval requests outside loops bulkifies data access and prevents SOQL 101 limit exceptions.

Modify records iteratively within a collection

Updated field values in memory using Assignment elements and added modified records to an output collection.

In-memory variable assignments do not count against governor execution limits.

Persist changes in bulk

Executed one Update Records element on the output collection after loop termination.

Performing a single DML operation on the collection minimizes transaction costs and respects DML governor limits.

Key Concept

Bulkification in Flow Builder

Question 1554Question →

An administrator at Crestview Real Estate built and activated a custom Matching Rule on the Contact object to identify duplicate records based on First Name, Last Name, and Phone Number. However, sales representatives report that they are still able to create identical Contact records without receiving any warnings or block messages. Which configuration step did the administrator fail to complete?

Creating and activating a Duplicate Rule that references the Matching Rule to specify the Alert or Block enforcement action.

Assigning the active Matching Rule directly to the Sales Representative User Profile permissions.

Adding the Matching Rule component to the Contact Lightning Record Page layout.

Changing the Organization-Wide Default (OWD) sharing setting for Contacts from Private to Public Read/Write.

Show answer & explanation

Answer: Creating and activating a Duplicate Rule that references the Matching Rule to specify the Alert or Block enforcement action.

Answer

Creating and activating a Duplicate Rule that references the Matching Rule to specify the Alert or Block enforcement action.

In Salesforce Duplicate Management, duplicate handling is split into two distinct elements: Matching Rules and Duplicate Rules. A Matching Rule defines the criteria used to identify duplicate records (e.g., exact match on First Name, Last Name, and Phone Number). However, the Matching Rule alone does not take any action. A Duplicate Rule must be created and activated to reference the Matching Rule and establish what action the system should execute (such as displaying an Alert, Blocking record creation, or generating a Duplicate Record Set report) when a duplicate is detected.

Step-by-Step Solution

Analyze the role of a Matching Rule in Salesforce Duplicate Management.

A Matching Rule defines the criteria (such as exact or fuzzy matching on specific fields) used to identify potential duplicate records.

Matching rules only evaluate data patterns; they do not dictate system actions upon encountering duplicates.

Analyze the role of a Duplicate Rule in Salesforce Duplicate Management.

A Duplicate Rule specifies what happens when a user creates or edits a duplicate record (such as allowing or blocking the record and triggering an alert or report).

Without an active Duplicate Rule referencing the Matching Rule, the system will not present warnings or prevent users from creating duplicate records.

Identify the missing configuration step in the scenario.

The administrator activated the Matching Rule but did not create/activate the corresponding Duplicate Rule to enforce the action.

Both matching rules and duplicate rules must be configured and activated for duplicate management to actively alert or block users.

Key Concept

Separation of Matching Rules (criteria identification) and Duplicate Rules (action enforcement)

Estimated Time:1m 30s

Question 1555Question →

A Salesforce Administrator is tasked with configuring declarative automation on the Case object. When a high-priority Case record is marked as Closed, the business process requires three distinct actions: creating a follow-up Task for the Account owner, posting a notification to the Account's Chatter feed, and deleting temporary diagnostic records related to the Case. Which statement accurately describes the capability of Process Builder regarding these requirements?

Process Builder can natively create the Task and post to the Chatter feed, but it cannot delete records directly without calling an autolaunched Flow or Apex code.

Process Builder can execute all three requested actions natively as immediate actions without referencing any external automation components.

Process Builder can natively perform record deletions, but posting to Chatter feeds requires invoking an Apex method.

Process Builder can only update fields on the triggering record, so creating related records and Chatter posts must be delegated to record-triggered flows.

Show answer & explanation

Answer: Process Builder can natively create the Task and post to the Chatter feed, but it cannot delete records directly without calling an autolaunched Flow or Apex code.

Answer

Process Builder can natively create the Task and post to the Chatter feed, but it cannot delete records directly without calling an autolaunched Flow or Apex code.

Process Builder natively supports creating new records (such as Tasks) and posting updates directly to Chatter feeds. However, it does not feature a native action for record deletion; performing a delete operation requires invoking an autolaunched Flow or Apex.

Step-by-Step Solution

Analyze native Process Builder immediate action capabilities

Identify that 'Create a Record' (Task) and 'Post to Chatter' are fully supported as built-in native actions in Process Builder.

Process Builder provides standard action types for record creation and social collaboration.

Evaluate the deletion requirement against declarative tool limits

Determine that Process Builder does not possess a native 'Delete Records' action type.

To delete records from a Process Builder trigger, an administrator must invoke an autolaunched Flow or an Apex class containing DML delete operations.

Key Concept

Process Builder Supported and Unsupported Actions

Question 1556Question →

A Salesforce Administrator at an IT infrastructure recycling firm needs to build a report for account managers. Management requires the report to group accounts into three distinct revenue categories based on Annual Revenue (Standard: up to $100,000; Premium:$ 100,001 to $500,000; Enterprise: over$ 500,000) without adding custom fields to the Account object. Additionally, the report must only list Accounts that currently have active Contracts, but do not have any open high-priority Cases. Which two steps should the administrator perform to satisfy these business requirements? (Select two.)

Select all that apply

Create a Bucket Field of type Text on the Annual Revenue field to define the Standard, Premium, and Enterprise ranges.

Add a Cross Filter for Accounts WITH Contracts (Status = Activated) and another Cross Filter for Accounts WITHOUT Cases (Status != Closed and Priority = High).

Define a Summary Formula field on the report to dynamically calculate and bucket the Annual Revenue into text groups.

Use standard field filter logic on the Account report to combine Account fields and related Case fields using nested OR statements.

Show answer & explanation

Answer: Create a Bucket Field of type Text on the Annual Revenue field to define the Standard, Premium, and Enterprise ranges.; Add a Cross Filter for Accounts WITH Contracts (Status = Activated) and another Cross Filter for Accounts WITHOUT Cases (Status != Closed and Priority = High).

Answer

The administrator should create a Bucket Field on the Annual Revenue field to group accounts into revenue categories, and apply Cross Filters to isolate Accounts WITH active Contracts and WITHOUT open high-priority Cases.

Creating a Bucket Field on the Annual Revenue field allows grouping numeric values into predefined categories directly within the report builder. Applying Cross Filters for 'Accounts WITH Contracts' and 'Accounts WITHOUT Cases' (with sub-filter criteria for open high-priority status) directly fulfills the requirement to include/exclude related child records without modifying the object structure.

Step-by-Step Solution

Configure a Bucket Field on Annual Revenue

Categorizes accounts into Standard, Premium, and Enterprise tiers without creating custom fields.

Bucket fields provide report-level grouping functionality across numeric ranges.

Add a Cross Filter for Accounts WITH Contracts

Filters the report to only include account records associated with active contracts.

Cross filters evaluate child record relationships.

Add a Cross Filter for Accounts WITHOUT Cases

Excludes accounts that have open high-priority cases.

Sub-filters on 'WITHOUT' cross filters evaluate specific negative relationship criteria.

Key Concept

Report Bucketing and Cross Filters

Question 1557Question →

An organization tracks product maintenance requests using a custom object named Warranty Claim. When a Warranty Claim status changes to 'Approved', two actions must occur automatically: a custom status timestamp field on the triggering Warranty Claim record must be updated, and a follow-up Task record must be created and assigned to the claim owner. Which TWO declarative automation solutions should a Salesforce administrator implement to fulfill these requirements efficiently?

Select all that apply

Configure a Record-Triggered Flow optimized for Fast Field Updates (before-save) to update the status timestamp on the triggering Warranty Claim record.

Configure a Record-Triggered Flow optimized for Actions and Related Records (after-save) to create the follow-up Task record.

Configure a single Record-Triggered Flow optimized for Fast Field Updates (before-save) to both update the triggering record timestamp and create the related Task record.

Create a Roll-Up Summary field on the parent Account object linked via a Lookup relationship to track and trigger Task creation for open warranty claims.

Show answer & explanation

Answer: Configure a Record-Triggered Flow optimized for Fast Field Updates (before-save) to update the status timestamp on the triggering Warranty Claim record.; Configure a Record-Triggered Flow optimized for Actions and Related Records (after-save) to create the follow-up Task record.

Answer

The administrator should use a Record-Triggered Flow set to Fast Field Updates (before-save) for updating fields on the triggering record itself, and a Record-Triggered Flow set to Actions and Related Records (after-save) for creating the related Task record.

Updating fields on the record that launched the flow is best handled by a before-save flow (Fast Field Updates) because it modifies the record in-memory prior to database save. Creating related records like Tasks requires an after-save flow (Actions and Related Records) because the system must finish committing the triggering record first.

Step-by-Step Solution

Evaluate the requirement for updating fields on the triggering record itself.

Identify that a before-save (Fast Field Updates) Record-Triggered Flow is optimal because it updates the triggering record before it is committed to the database, avoiding extra DML operations.

Before-save execution optimizes system performance when updating values on the record that launched the flow.

Evaluate the requirement for creating a related Task record.

Identify that an after-save (Actions and Related Records) Record-Triggered Flow is required to create related records after the initial record ID exists.

Creating related records involves external database writes that cannot occur within a before-save context.

Key Concept

Selecting the correct trigger timing (before-save vs. after-save) in Flow Builder based on whether automation targets the triggering record or related records.

Question 1558Question →

A Salesforce Administrator needs to design an autolaunched flow that updates the Status field of all active Contact records associated with an Account whenever the Account's Status changes to 'Inactive'. The solution must process multiple child records efficiently without exceeding system governor limits. How should the administrator construct the flow logic?

Query related active Contacts with a Get Records element, loop through the collection, update each record's Status field in an Assignment element while adding it to a new collection variable, and execute a single Update Records element on the collection after the loop.

Query related active Contacts with a Get Records element, loop through the collection, and place an Update Records element inside the loop to save changes to each Contact individually.

Create a Roll-Up Summary field on the Account to fetch and update child Contact statuses directly without using collection variables or loop structures.

Loop through the child Contacts and use a Decision element to assign picklist values directly without adding the modified records to a record collection variable.

Show answer & explanation

Answer: Query related active Contacts with a Get Records element, loop through the collection, update each record's Status field in an Assignment element while adding it to a new collection variable, and execute a single Update Records element on the collection after the loop.

Answer

The correct approach bulkifies flow operations by gathering updated child records into a record collection variable using Assignment elements inside the loop, followed by a single Update Records element after the loop completes. This pattern ensures that database operations are minimized, adhering to Salesforce governor limits.

Step-by-Step Solution

Retrieve related child records

Obtain a collection variable containing active Contacts for the Account using one Get Records element outside the loop.

Retrieving all records in a single query avoids executing SOQL queries inside a loop.

Process records in memory using a Loop and Assignment elements

Iterate through each Contact record, update its Status field, and add the updated record to a target collection variable.

Assignment elements modify record variables in memory without invoking database transactions or consuming DML limits.

Persist changes using a single DML operation

Pass the modified collection variable into a single Update Records element located after the loop ends.

Executing database operations outside the loop ensures the flow bulkifies correctly and respects Salesforce governor limits.

Key Concept

Flow Bulkification and Collection Processing

Question 1559Question →

A Salesforce Administrator is evaluating declarative tools for automated business processes. Match each business automation requirement on the left with its corresponding Process Builder capability or limitation on the right.

Click a left item, then click its matching right item

Show answer & explanation

Answer

1. Sending a follow-up email 3 days post-close matches 'Supported natively using Process Builder Scheduled Actions'. 2. Creating a follow-up Task record matches 'Supported natively using Process Builder Immediate Actions (Create a Record)'. 3. Submitting a record to an approval process matches 'Supported natively using Process Builder Immediate Actions (Submit for Approval)'. 4. Deleting related child records matches 'Not supported in Process Builder; requires Flow Builder or Apex'.

Process Builder natively supports creating new records, submitting records to approval processes, and delaying action execution using Scheduled Actions. However, direct record deletion is outside of Process Builder's feature set and requires Flow Builder or Apex code.

Step-by-Step Solution

Analyze time-delayed automation requirement.

Sending an email alert 3 days after an Opportunity is closed relies on time-dependent triggers, which Process Builder supports via Scheduled Actions.

Scheduled Actions allow executing process actions relative to specific record dates or execution times.

Analyze record creation requirement.

Generating a new Task record when a Case escalates uses Process Builder's immediate 'Create a Record' action.

Creating child or related records is a core native capability of Process Builder.

Analyze approval process automation requirement.

Submitting a record automatically to an approval process uses Process Builder's 'Submit for Approval' immediate action.

Process Builder natively supports invoking existing active approval processes without custom code.

Analyze record deletion requirement.

Deleting records is identified as a platform limit in Process Builder, requiring Flow Builder or Apex.

Process Builder does not feature a native delete action element.

Key Concept

Process Builder Capabilities and Limitations

Question 1560Question →

A Salesforce Administrator is creating an after-save record-triggered flow on the Account object to update the mailing address on all child Contact records whenever an Account address changes. To adhere to Salesforce bulkification design principles and prevent hitting governor limits, in which sequence should the administrator execute the flow steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct bulkified execution sequence is: 1) Query child Contact records using Get Records, 2) Iterate over the collection with a Loop element, 3) Update field values on the current record using an Assignment element inside the loop, 4) Add the updated record to a target collection variable using a second Assignment element inside the loop, and 5) Execute an Update Records element on the target collection outside of the loop.

The standard bulkification design pattern in Salesforce Flow Builder requires retrieving records once using Get Records, iterating through the collection with a Loop, updating fields on the current item in an Assignment, appending that item to an update collection in a second Assignment, and executing a single Update Records DML operation on the collection after the loop completes.

Step-by-Step Solution

Retrieve related child records using a Get Records element outside any loop structure.

Obtains a Record Collection containing all target Contact records.

Data queries must be executed outside loops to conserve SOQL query limits.

Initialize a Loop element to iterate through the retrieved Contact Record Collection.

Sets the current iteration item for step-by-step modification.

Looping allows row-by-row field value updates in memory.

Add an Assignment element inside the loop to modify field values on the current iteration item.

Populates updated address values on the loop item variable.

Memory modifications on loop variables do not consume DML governor limits.

Add a secondary Assignment element inside the loop to append the current loop item to a dedicated Update Collection variable.

Gathers all updated records into a single collection payload.

A separate collection variable is required to perform a single batch update after iteration ends.

Place an Update Records element after the loop path completes, targeting the Update Collection variable.

Executes one DML update statement for all modified Contact records.

Placing DML elements outside of loops prevents governor limit violations such as Too Many DML Statements.

Key Concept

Flow Bulkification Pattern (SOQL/DML outside Loops)

PreviousPage 78 / 90Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept