CCNA Automation Questions

MCQhard

Universal Containers has a Record-Triggered Flow on the Case object that runs when a Case is created or updated and sends a notification email to the assigned owner. During testing, the administrator notices the flow sends duplicate emails when a user edits a Case twice within a few seconds. The administrator needs the flow to run only when the Case's Priority field actually changes value. Which configuration should the administrator apply?

A.Create a validation rule on the Case object that blocks saves when Priority is unchanged, forcing users to modify the field before the record can be saved.

B.Configure the flow to run asynchronously so that rapid successive edits are consolidated into a single scheduled interview before the notification is sent.

C.Set the Start element to run only when a record is updated, and add an entry condition comparing the PriorValue of Priority to its current value.

D.Add a Decision element immediately after the Start element that checks whether the record's Priority equals High, and route non-matching records to an end element.

AnswerC

Entry conditions on an update-triggered Start element can reference $Record__Prior, which exposes the field values stored in the database before the save. Comparing Priority's prior value to its current value makes the flow fire only on a genuine change, eliminating the duplicate sends caused by unrelated edits that leave Priority untouched.

Why this answer

Record-Triggered Flows that start on create or update fire on every qualifying save, so unrelated edits can re-trigger notifications. Restricting the Start element to updates and adding an entry condition that compares the prior stored value of Priority against the incoming value ensures the automation runs only when that specific field is genuinely modified, which removes the duplicate sends without blocking other edits.

Exam trap

The trap here is assuming a Decision element can detect that a field changed, when it only evaluates the record's current values and cannot see the pre-save state.

Practice this question →

MCQhard

An administrator at Cloud Kicks has a Record-Triggered Flow on the Case object that runs after save and sends an email notification. During testing, the administrator notices that the flow sometimes sends duplicate emails when a Case is updated multiple times in quick succession. Which action should the administrator take to prevent duplicate email notifications?

A.Use a formula in the entry condition to check that the PriorValue of the Status field is not equal to the current value.

B.Add a Decision element that checks if an email has already been sent for this Case using a custom field or a related record.

C.Configure the flow to run asynchronously to batch multiple updates.

D.Add an entry condition to the Start element that checks if the Status field is changed to 'Escalated'.

AnswerB

Using a Decision element to check a custom field or related record that tracks whether an email has already been sent prevents duplicate notifications. The administrator can set a flag when the email is sent and check it before sending again. This ensures the email is sent only once per Case or per relevant event, directly addressing the duplicate email issue.

Why this answer

The most reliable way to prevent duplicate email notifications is to track whether an email has already been sent and check that status before sending again. A Decision element that evaluates a custom field or related record ensures the email is sent only once, even if the flow is triggered multiple times. This approach directly solves the duplicate email problem, whereas other options only limit when the flow runs without guaranteeing single execution.

Exam trap

The trap here is focusing on entry conditions or execution mode when the real solution requires tracking the email-sent state to prevent multiple sends.

Practice this question →

MCQeasy

An administrator at Universal Containers needs to create a Record-Triggered Flow that updates the 'Renewal_Date__c' field on an Opportunity when the Opportunity's Stage is changed to 'Closed Won'. The administrator wants to ensure the update happens before the record is saved to the database. Which type of Flow element should the administrator use to update the record before it is saved?

A.Create Records element in a before-save path.

B.Update Records element in an after-save path.

C.Assignment element in an after-save path.

D.Update Records element in a before-save path.

AnswerD

In a Record-Triggered Flow, the before-save path allows you to update the triggering record's fields before the record is saved to the database. Using an Update Records element in this path ensures the field is updated in the same transaction, without an additional DML operation. This is the correct approach for updating the record before save.

Why this answer

To update the Opportunity's Renewal Date before the record is saved, the administrator should use an Update Records element in the before-save path. This path is specifically designed for updating the triggering record's fields before commit, avoiding additional DML statements. The after-save path is for actions after the save, and other elements like Create Records or Assignment do not update the record.

Exam trap

The trap here is confusing the before-save and after-save paths, thinking that any update element can be used in either path.

Practice this question →

Multi-Selectmedium

A sales manager at Get Cloudy Consulting wants a Record-Triggered Flow to update the 'Next Step' field on an Opportunity and also create a follow-up Task whenever the Opportunity stage changes to 'Negotiation'. The administrator is configuring the flow's start conditions. Which two considerations should the administrator keep in mind when designing this flow? (Choose two.)

Select 2 answers

A.The flow must use an after-save configuration to create a related Task record.

B.The flow can create the Task in a before-save flow if the Task is related to the Opportunity.

C.The flow must use a scheduled path to create the Task at a later time.

D.The flow can update the triggering Opportunity record without using a separate Update Records element if it is a before-save flow.

E.The flow can update the Opportunity and create the Task in a single before-save flow.

AnswersA, D

Creating a Task is a DML operation on a different record, which requires an after-save flow. Before-save flows cannot perform DML on other records; they can only modify the triggering record. Therefore, to create a follow-up Task, the administrator must use an after-save flow. This is a key design consideration for the described automation.

Why this answer

A before-save flow can update fields on the triggering Opportunity using the $Record variable without a separate Update Records element, which is efficient. However, creating a Task requires DML on a different record, so an after-save flow is necessary. These two considerations guide the administrator to design a flow that updates the Opportunity in a before-save context and creates the Task in an after-save context, or to use a single after-save flow for both actions.

Exam trap

The trap here is assuming that a single before-save flow can both update the triggering record and create related records, when DML on other records is not allowed in before-save flows.

Practice this question →

MCQmedium

Cloud Kicks needs a process to automatically update the 'Account Status' field on all related Contacts to 'Inactive' whenever an Account's status is changed to 'Closed'. Which automation tool should the administrator use to achieve this with the least amount of maintenance?

A.Workflow Rules

B.Approval Process

C.Record-Triggered Flow

D.Apex Trigger

AnswerC

Record-Triggered Flows are the standard declarative tool for cross-object updates in modern Salesforce orgs. By utilizing an after-save flow, the administrator can efficiently update related child records, ensuring that the automation runs predictably and integrates natively with the Salesforce transaction model for better performance and error handling.

Why this answer

Record-Triggered Flows are the recommended tool for cross-object field updates in Salesforce. They replace legacy workflows and process builders because they are more efficient and execute before or after database changes. By using an after-save flow, the administrator can easily traverse the Account-Contact relationship to perform bulk updates while ensuring the process remains declarative, scalable, and highly visible within the Flow Builder interface for future maintenance.

Exam trap

Candidates often choose Apex triggers because they are familiar with coding. However, Salesforce best practices dictate using Record-Triggered Flows for cross-object updates whenever possible to reduce maintenance and complexity.

Practice this question →

Multi-Selectmedium

Universal Containers wants to build a Screen Flow that collects a Case's priority and description, then creates a Case record and immediately sends a confirmation email. The administrator must ensure the Flow can perform both operations in a single interview. (Choose two.)

Select 2 answers

A.Use a Wait element configured to resume after one minute, then send the email.

B.Use a Post to Chatter action to notify the support team instead of sending email.

C.Use a Record-Triggered Flow with a before-save update to insert the Case.

D.Use a Create Records element to insert the Case record.

E.Use an Action element referencing the standard Send Email action.

AnswersD, E

The Create Records element is the standard Flow element for inserting new records. It can create one or many records and stores the resulting record Id in a variable. In a Screen Flow, this element runs after the user submits the screen, creating the Case before the confirmation email is sent, which satisfies the requirement.

Why this answer

A Screen Flow can both create records and send email within one interview. The Create Records element inserts the Case and returns its Id, and the Send Email core action then sends a confirmation using that Id. Together they satisfy the requirement without Apex or a separate trigger-based Flow.

Exam trap

The trap here is reaching for a Record-Triggered Flow to insert the record, when a Screen Flow can create records directly with a Create Records element.

Practice this question →

MCQhard

A Salesforce administrator is asked to automate a multi-step approval process for discount requests on Opportunity. The process must route to different approvers based on the discount percentage, allow approvers to reject with comments, and update the Opportunity stage upon final approval. The administrator wants to build this declaratively without code. Which tool should be used?

A.Einstein Next Best Action with a recommendation strategy.

B.Approval Process with steps and approval actions.

C.Record-Triggered Flow with a decision element and an approval action.

D.Scheduled-Triggered Flow that checks discount fields nightly and assigns tasks to approvers.

AnswerB

Approval Processes are purpose-built for sequential or parallel approval routing, support multiple steps with different approver assignments based on record criteria, allow rejections with comments, and can execute approval actions such as field updates and email alerts. This matches every requirement declaratively and is the standard Salesforce tool for approval routing without code.

Why this answer

Approval Processes are the declarative Salesforce feature designed specifically for routing records to approvers, supporting multiple steps with criteria-based approver selection, rejection with comments, and post-approval actions like field updates. The other options either lack native approval mechanics or require custom development to approximate them, making Approval Processes the correct choice for this requirement.

Exam trap

The trap here is assuming Flow can replace Approval Processes because it can submit for approval, when the native approver routing, rejection comments, and audit trail are only fully provided by Approval Processes.

Practice this question →

Multi-Selecthard

An administrator at Northern Trail Outfitters is building a Record-Triggered Flow on Account that must update related Contacts when the Account's BillingCountry changes. The administrator wants to ensure the flow runs efficiently and only when necessary. Which TWO considerations should the administrator apply? (Choose two.)

Select 2 answers

A.Set the flow to run only when a record is created, not updated.

B.Use a before-save flow to update the Account's BillingCountry field directly without additional DML.

C.Add an entry condition that checks PRIORVALUE(BillingCountry) is different from the current BillingCountry.

D.Use a Get Records element to retrieve related Contacts and an Update Records element to modify them.

E.Configure the flow to run asynchronously to avoid governor limits.

AnswersC, D

Using PRIORVALUE() in the entry condition ensures the flow fires only when BillingCountry actually changes. This prevents unnecessary executions on updates that do not modify the country, improving efficiency and avoiding redundant Contact updates. It directly addresses the requirement to run only when necessary.

Why this answer

The flow should fire only when BillingCountry changes, which is achieved by comparing PRIORVALUE() with the current value in the entry condition. To update related Contacts, the flow must retrieve them with Get Records and then update them with Update Records. Together, these two choices ensure the flow runs efficiently and only when necessary, while correctly performing the cross-object update.

Exam trap

The trap here is assuming that a before-save flow can update related records or that asynchronous execution solves efficiency, when the real requirements are a transition check and a query-then-update pattern.

Practice this question →

MCQmedium

An administrator at Cloud Kicks has built a Record-Triggered Flow on Opportunity that fires when Stage changes to 'Closed Won'. The flow sends a notification email to the opportunity owner. Testing shows the email fires multiple times for a single stage change when the opportunity is updated by an integration user. The administrator wants to ensure the email is sent only once per opportunity close. What should the administrator do?

A.Set the flow to run asynchronously so that it processes only the most recent update.

B.Configure the flow to run only when the record is updated by a specific user.

C.Add a condition to check that the prior value of Stage is not 'Closed Won' and the current value is 'Closed Won'.

D.Change the flow trigger to run only when a record is created and set the Stage to 'Closed Won' by default.

AnswerC

Using the PRIORVALUE() function in a formula entry condition ensures the flow only fires on the transition into 'Closed Won'. Subsequent updates where Stage remains 'Closed Won' will not satisfy the condition, preventing duplicate notifications regardless of who or what triggers the update. This is the standard pattern for one-time transition automation.

Why this answer

The duplicate emails occur because the entry condition matches any update where Stage equals 'Closed Won', including updates that do not change Stage. Using PRIORVALUE() to detect the actual transition from a different stage into 'Closed Won' ensures the flow fires exactly once per close. This is the recommended pattern for one-time transition automation in Record-Triggered Flows.

Exam trap

The trap here is assuming that filtering by the running user or switching to asynchronous execution prevents duplicate flow executions, when the real fix is detecting the stage transition itself.

Practice this question →

MCQeasy

Cloud Kicks wants a Flow to run every time a Contact's Email field is updated to a new value, but not when other fields change. The administrator is configuring the Start element of a Record-Triggered Flow. Which configuration should be selected?

A.Select 'A record is created or updated' and set the condition to Email Is Changed True.

B.Select 'A record is updated' and add a Decision element that compares Email to a stored copy.

C.Select 'A record is updated' and set the condition to Email Is Changed True.

D.Select 'A record is created or updated' and set the condition to Email Is Null False.

AnswerC

Record-Triggered Flows support the Is Changed operator in entry conditions, which evaluates whether a specified field's value differs from its prior value. Setting Email Is Changed True ensures the Flow fires only when the Email field changes, ignoring updates to other fields. This is the precise way to scope the trigger.

Why this answer

The Is Changed operator in a Record-Triggered Flow's Start element detects whether a field's value differs from its previous value. Combining 'A record is updated' with Email Is Changed True scopes the Flow precisely to Email updates and excludes creations and unrelated field changes, which is exactly what Cloud Kicks needs.

Exam trap

The trap here is using Is Null or a custom comparison instead of the native Is Changed operator, which already detects value differences on update.

Practice this question →

Multi-Selecthard

An administrator at Northern Trail Outfitters is building a Record-Triggered Flow on the Case object that must run when a Case is created and the Priority is 'High'. The flow needs to update the Case's Status to 'Escalated' and then send an email to the case owner. Which TWO configurations are required to ensure the flow runs only when the Case is created and the Priority is 'High'? (Choose two.)

Select 2 answers

A.Configure entry criteria with a condition that Priority equals 'High'.

B.Set the flow's trigger to run on create only.

C.Set the flow to run in system context without sharing.

D.Add a Get Records element to retrieve the Case's Priority.

E.Add a Decision element that checks if the Priority equals 'High'.

AnswersA, B

Entry criteria are evaluated before the flow executes, so setting a condition that Priority equals 'High' ensures the flow only runs for High priority Cases. This is the most efficient way to filter and is a required configuration to meet the requirement without unnecessary flow executions.

Why this answer

To ensure the flow runs only when a Case is created and the Priority is 'High', the administrator must set the trigger to run on create only and configure entry criteria that check if Priority equals 'High'. Entry criteria are evaluated before the flow runs, making them the most efficient filter. A Decision element could also check Priority, but entry criteria are the standard configuration for this purpose.

Exam trap

The trap here is thinking that a Decision element inside the flow is sufficient, when entry criteria are the proper configuration to prevent the flow from running unnecessarily.

Practice this question →

MCQmedium

An administrator at Northern Trail Outfitters is configuring a Record-Triggered Flow on the Opportunity object. The flow must execute only when an Opportunity is updated and the Stage field changes to Closed Won. Which configuration should the administrator use to meet this requirement?

A.Set the Start element to run when a record is updated, and configure the entry condition to check if Stage equals Closed Won.

B.Set the Start element to run when a record is created or updated, and configure the entry condition to check if Stage is changed and equals Closed Won.

C.Set the Start element to run when a record is created or updated, and add a Decision element that checks if Stage equals Closed Won.

D.Set the Start element to run when a record is updated, and configure the entry condition to check if Stage is changed and equals Closed Won.

AnswerD

This configuration restricts the flow to update events and uses the ISCHANGED operator on the Stage field combined with an equality check for Closed Won. The flow executes only when an update occurs and the Stage field transitions to Closed Won. This precisely matches the requirement of running when an Opportunity is updated and the Stage changes to Closed Won.

Why this answer

The correct configuration limits the flow to update events and uses the ISCHANGED operator on the Stage field along with an equality check for Closed Won. This ensures the flow runs only when an update causes Stage to transition to Closed Won, avoiding unnecessary executions on creation or on updates where Stage was already Closed Won. It precisely satisfies the stated automation requirement.

Exam trap

The trap here is confusing a simple equality condition on Stage with the ISCHANGED operator, which is required to detect that the field transitioned to the desired value.

Practice this question →

MCQmedium

An administrator wants to automate a process that requires a user to confirm they want to proceed before the record is updated. Which tool should the administrator choose?

A.Record-Triggered Flow

B.Screen Flow

C.Scheduled Flow

D.Platform Event-Triggered Flow

AnswerB

Screen Flows are built specifically for user-facing interactive processes. They allow administrators to build custom interfaces with input components, including checkboxes or buttons for confirmation. This interactivity is required when the business process demands manual user input or validation before moving to the next stage of the workflow.

Why this answer

Screen Flows are the only declarative automation tool that allows for user interaction through a UI. By placing a screen element, the administrator can prompt users for input or confirmation. This is essential when the automation logic depends on human judgment or manual verification, which cannot be achieved through record-triggered background automation.

Screen flows provide the necessary interface to engage users in a guided, consistent business process.

Exam trap

Candidates frequently suggest Record-Triggered Flows for user confirmation. Record-Triggered Flows run in the background and cannot pause to wait for user input, making them unsuitable for interactive confirmation prompts.

Practice this question →