Automation practice questions

Use a Decision element to check if Rating equals Hot.

Why it fails: While a Decision element could evaluate the rating, it is less efficient than using entry conditions. Entry conditions prevent the flow interview from starting entirely if the criteria are not met, whereas a Decision element requires the flow to begin and consume governor limits before evaluating the logic.

Set the trigger to run on create or update.

Why it fails: Setting the trigger to run on both create and update would cause the flow to execute every time a Lead is modified, even if the Rating is not Hot. This leads to inefficient execution and potential performance issues, as the logic would run far more frequently than required.

Set the entry condition to Lead Source Equals Web.

Why it fails: The requirement specifically states that the trigger should be based on the Lead 'Rating' being 'Hot'. Including 'Lead Source' as an entry condition would incorrectly filter the records and prevent the automation from firing on Hot leads that originated from sources other than the Web.

Send an email alert.

Why it fails: Sending an email alert is an action that requires data to be committed to the database first. Because before-save flows occur before the record is saved, asynchronous or external actions are not permitted in this context. These must be performed in an after-save flow or via an asynchronous path.

Create a related record.

Why it fails: Before-save flows only allow modifications to the record that triggered the flow. Creating or updating related records (parent or child) requires an after-save flow, as these operations depend on the primary record being successfully committed to the database and having an assigned ID during the transaction.

Debug as Another User

Why it fails: Debugging as another user is primarily used to test security and field-level access permissions. It does not provide the detailed field value comparison needed to troubleshoot logic errors within the flow's internal processing. This setting is more relevant for testing user permissions rather than the flow's internal performance.

Show Governor Limits

Why it fails: While showing governor limits is useful for performance tuning, it does not display the record field values. This setting helps identify if the flow is hitting threshold limits but fails to show the specific data mutations applied to the record, which is the primary goal of the administrator's request.

Run as Rollback Mode

Why it fails: Rollback mode ensures that changes made during the debug session are not saved to the database. While it prevents data corruption, it is not the setting that explicitly displays the 'Before' and 'After' field values for inspection. It is a safety feature, not a data visualization tool.

Add a decision element after the trigger that checks if the escalation field is true.

Why it fails: Checking only the current value of the escalation field will still allow the email to send on any update where the field is true, including updates that do not change the field. The problem is not the current value but the transition, so a simple true check does not prevent duplicate sends when the field remains true across multiple updates.

Change the flow to run before-save and use a field update to set the escalation flag.

Why it fails: Before-save flows are intended for fast field updates on the triggering record and cannot send emails or perform actions that require a record ID. Moving the email action to a before-save flow is not supported, and setting the escalation flag in the flow does not address the duplicate-send issue. This option misuses before-save timing.

Add a fault path to the email action that logs errors and retries the email only once.

Why it fails: A fault path handles errors from the email action, such as delivery failures, but does not control how many times the flow qualifies to run. The duplicate email is caused by the flow executing on multiple updates, not by an error in the email action itself. Retrying on fault would not prevent the initial duplicate sends.

Scheduled-Triggered Flow that runs daily and queries converted Leads.

Why it fails: A scheduled flow runs on a fixed schedule and cannot react immediately to a conversion event. It would also need to track which Leads have already been processed to avoid duplicate tasks, adding complexity. This approach introduces delay and does not satisfy the immediate execution requirement.

Process Builder with a scheduled action.

Why it fails: Process Builder is a legacy tool that Salesforce has deprecated in favor of Flow. While it could historically create tasks, scheduled actions run at a future time rather than immediately after conversion, and the tool is no longer recommended for new automation. It does not meet the immediate execution requirement as cleanly as Flow.

Workflow Rule with a time-dependent action.

Why it fails: Workflow Rules are also legacy and cannot create Tasks directly; they can only create tasks via a task action, but time-dependent actions are queued and run later, not immediately. Workflow Rules are being retired and should not be used for new automation. This option does not provide immediate task creation on conversion.

Scheduled Flow that runs nightly to find all Invoices with Status__c = 'Paid' and updates the related Account's Last_Paid_Date__c.

Why it fails: A scheduled flow would not run immediately when the status changes and could update Accounts multiple times for the same invoice, causing incorrect dates. It also does not meet the requirement to update only upon the status change to Paid.

Workflow Rule on Invoice__c with a field update on Account.

Why it fails: Workflow rules cannot update fields on a related record through a lookup; they only update the record that triggered the rule. They also cannot reference ISCHANGED in the criteria in the same manner, and are deprecated for new automation.

Process Builder on Invoice__c with a criteria node for Status__c = 'Paid' and an immediate action to update the Account.

Why it fails: Process Builder is a legacy tool that Salesforce is retiring; new automation should not use it. Even if used, it cannot evaluate ISCHANGED in the same way, and it would not reliably limit the update to only when the status changes to Paid.

A Create Records element that creates an EmailMessage record.

Why it fails: Creating an EmailMessage record does not send an email; it merely creates a record in Salesforce. EmailMessage records are typically created by Email-to-Case or similar inbound processes, not for outbound notifications. This approach would not deliver the confirmation email.

A Post to Chatter action configured to mention the opportunity owner.

Why it fails: Post to Chatter creates a Chatter post, not an email. While it can notify the owner, it does not satisfy the requirement to send a confirmation email. Chatter posts are also subject to feed visibility settings and may not reach the owner via email.

A Send Email action placed before the Update Records element in the immediate path.

Why it fails: Placing the Send Email action before the Update Records element in the immediate path sends the email before the record is committed, and if the update fails, the email may still be sent, leading to inconsistent notifications. The requirement specifies after the record is saved, so this placement is incorrect.

Record-Triggered Flow

Why it fails: Record-Triggered Flows run automatically in the background when records are created, updated, or deleted, without any user interaction. They cannot present interactive screens for data entry, so they cannot collect the qualification details step by step. They are suited for automating field updates, creating related records, or sending notifications, not for guiding a rep through a data-entry wizard.

Scheduled-Triggered Flow

Why it fails: Scheduled-Triggered Flows run on a defined schedule and operate in the background without user interaction. They are appropriate for time-based batch processing, such as nightly cleanup or reminder emails, but they cannot present screens to collect qualification details. This tool does not provide the guided, interactive experience the sales team needs after a Lead is created.

Approval Process

Why it fails: An Approval Process routes records to designated approvers for a decision and can lock records during review, but it does not present a guided data-entry sequence. It is designed for authorization workflows, not for capturing qualification details step by step. It also requires the record to already exist and does not collect arbitrary user input through screens.

The flow uses a Get Records element that retrieves multiple Case records.

Why it fails: A Get Records element retrieving multiple Case records would not cause the Task to be created multiple times for the same Case unless the flow loops over those records. The scenario describes a Record-Triggered Flow on a single Case, so the Get Records element is likely retrieving related records, not causing duplication.

The flow is configured to run in system context without sharing, causing it to bypass duplicate rules.

Why it fails: Running in system context without sharing affects record access, not the number of times the flow executes. Duplicate rules are for record creation, not for Task creation. This setting would not cause multiple Tasks to be created for the same Case.

The flow has a scheduled path that runs every time the Case is updated.

Why it fails: A scheduled path runs at a specified time, not every time the Case is updated. Scheduled paths are time-based and would not cause multiple Tasks unless the Case is updated multiple times and the scheduled path is set to run on each update, which is not typical. The scenario does not mention a scheduled path.

Set the flow to run asynchronously to allow the validation rule to be ignored.

Why it fails: Asynchronous execution does not bypass validation rules; it only changes when the flow runs relative to the triggering transaction. The validation rule would still fire and cause the same failure, so this does not solve the problem.

Deactivate the validation rule on the Contract object.

Why it fails: Deactivating the validation rule would remove a business-critical constraint and could allow invalid data to be saved. This is not a recommended solution because it compromises data integrity and does not address the flow's error handling.

Configure the flow to run in system context without sharing to bypass the validation rule.

Why it fails: Running in system context without sharing does not bypass validation rules; validation rules are enforced regardless of the running user's permissions. This action would not resolve the error and could introduce security risks by ignoring sharing settings.

Configure the flow on the Task object with a trigger on create and update, and use a Decision element to check if the Task is new.

Why it fails: A flow on the Task object with create and update triggers would run on both Task creation and update. Although a Decision element can check if the Task is new, it would still run on updates, potentially causing unnecessary executions and not strictly meeting the requirement to run only on creation.

Configure the flow on the Account object with a trigger on create or update, and use a Get Records element to check for new Tasks.

Why it fails: Running the flow on Account create or update would not specifically target Task creation. It would run on any Account change, and checking for new Tasks would require complex logic to compare timestamps, which is not efficient and may miss Tasks created without updating the Account.

Configure the flow on the Account object with a trigger on update, and use a Decision element to check if the update is due to a Task creation.

Why it fails: A flow on the Account object with an update trigger would run whenever the Account is updated, regardless of whether the update is due to a Task creation. There is no reliable way to determine the cause of the update within the flow, making this approach ineffective for the requirement.

Add an Assignment element that sets a default Contact Id before the Get Records element runs.

Why it fails: Pre-populating a Contact Id does not address the case where the query returns no records; the Get Records element overwrites the variable with null when nothing matches. The Flow would still attempt to use a null value downstream. Assignment cannot substitute for a conditional check on the query result.

Add a Fault Path on the Get Records element that sends an email to the administrator.

Why it fails: Get Records does not throw a fault when it returns zero records; it simply returns a null variable. A Fault Path only handles unexpected exceptions such as query errors or governor limit breaches. Configuring a fault connector here would not prevent the null-reference failure that occurs later in the Flow when the email action tries to use the missing Contact.

Change the Get Records element to 'Store All Records' and loop through the collection.

Why it fails: Storing all records returns a collection that may be empty, but the Flow still needs logic to detect the empty collection before iterating. A Loop over an empty collection simply produces no iterations, so the subsequent email action would still receive no valid Contact and could fail or send incorrectly. The underlying null-handling requirement is unchanged.

Set the flow to run in system context and review the debug output.

Why it fails: Running a flow in system context affects permissions and sharing, not the level of debugging detail. It does not provide a step-by-step view of variable values or field data. System context is used to bypass user permissions, but it does not enhance debugging capabilities. The administrator needs to use the Flow Debugger for detailed inspection.

Enable debug logs for the user.

Why it fails: Debug logs capture Apex execution, database operations, and some flow details, but they do not provide a step-by-step view of flow variables and record fields as the flow executes. They are more useful for Apex debugging and general system activity. For detailed flow debugging, a specialized flow debug feature is required.

Use the Flow Debugger with 'Show details' enabled.

Why it fails: The Flow Debugger in Flow Builder allows stepping through a flow and viewing variable values, but 'Show details' is not a specific option that provides the exact field values at each step. The debugger does show variable values, but the administrator needs to ensure the debug mode is set correctly. This option is not the precise setting that enables detailed field value inspection.

The Flow needs a Scheduled Path because before-save Flows cannot update the triggering record.

Why it fails: Before-save Record-Triggered Flows are specifically designed to update the triggering record without additional DML statements, making them the most efficient choice for field updates. They absolutely can update fields on the record that fired them. The issue is not the Flow type but the ordering relative to other automation such as assignment rules.

The Flow is running in system context and cannot modify the OwnerId field.

Why it fails: Record-Triggered Flows that run before save can modify OwnerId when the running user has the 'Transfer Cases' permission and access to the target queue. Running in system context does not by itself prevent ownership changes. The observed behavior of the Flow executing but the owner not changing points to a different root cause than context permissions.

The administrator must enable 'Run Flow in System Context with Sharing' in the Flow properties.

Why it fails: There is no Flow property named 'Run Flow in System Context with Sharing.' Record-Triggered Flows have a 'Run in System Context with Sharing' option, but enabling sharing enforcement would restrict access rather than grant the ability to change OwnerId. This setting is unrelated to the ordering conflict with assignment rules that is causing the symptom.

Increase the SOQL query limit by enabling 'Bypass Governor Limits' in the Flow properties.

Why it fails: Salesforce does not provide a 'Bypass Governor Limits' property on Flows. Governor limits are enforced by the platform and cannot be disabled by an administrator. This option describes a nonexistent feature and would not resolve the limit error.

Convert the Flow to a Process Builder process, which is exempt from SOQL limits.

Why it fails: Process Builder is not exempt from governor limits and is in fact being retired in favor of Flow. Converting to Process Builder would not change the underlying limit consumption and could introduce additional overhead. This option misstates platform behavior and does not address bulkification.

Add a Fault Path to the Flow that catches the limit exception and retries the operation.

Why it fails: Governor limit exceptions such as 'Too many SOQL queries' are not recoverable within the same transaction; a Fault Path cannot retry the operation because the transaction is already compromised. Catching the fault would not restore the ability to execute additional queries. The real fix is to reduce the number of operations through bulkification.

Workflow Rules

Why it fails: Workflow rules are a deprecated feature that does not support cross-object field updates for child records like Contacts. Salesforce recommends migrating all existing workflow logic to Flow as part of the ongoing transition to more robust, modern, and efficient declarative automation tools that offer superior debugging capabilities.

Approval Process

Why it fails: Approval processes are designed for multi-step organizational sign-off workflows rather than automated data synchronization. They require manual user intervention to trigger record updates, making them unsuitable for an automated background process that updates related Contact records whenever an Account status changes to a specific value.

Apex Trigger

Why it fails: Apex triggers require custom code development and ongoing maintenance by a developer. Unless the business logic is too complex for Flow, administrative best practices dictate using declarative tools like Record-Triggered Flows to minimize technical debt and allow non-developers to manage the business logic without writing code.

Record-Triggered Flow

Why it fails: Record-Triggered Flows operate entirely in the background and do not support user interaction. They are designed to automate system processes based on database changes. If a process requires a user to see a screen or confirm an action, a record-triggered flow is not the correct tool.

Scheduled Flow

Why it fails: Scheduled flows run automatically at a specific time on a batch of records. They do not have the ability to interact with a user, as they are not triggered by a user's action in the interface. They are intended for background processing tasks, such as nightly data cleanups.

Platform Event-Triggered Flow

Why it fails: Platform Event-Triggered flows are designed to respond to system-level events or messages, running in the background without user interaction. Because they are driven by events rather than user UI sessions, they cannot display screens or solicit input, making them unsuitable for any process requiring user confirmation.

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.

Why it fails: A validation rule prevents the record from being saved at all, which blocks legitimate edits to other fields such as Status or Description. This harms normal user work instead of scoping the flow, and it cannot distinguish which automation should run based on a field-level change.

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

Why it fails: Running a Record-Triggered Flow asynchronously defers execution to a future transaction but does not deduplicate or coalesce separate save events. Two edits still produce two asynchronous interviews, so two emails are still sent; asynchrony affects timing and governor limits, not change detection.

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.

Why it fails: A Decision element evaluates the record as it exists after the change, not what changed. If a Case already has Priority set to High, every subsequent edit still passes the check and the notification fires again, so the duplicate-email problem persists rather than being solved by this routing logic.

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

Why it fails: Asynchronous execution changes when the flow runs but does not deduplicate events. Each qualifying update still enqueues its own flow interview, so multiple updates with Stage equal to 'Closed Won' would still send multiple emails. Asynchronous execution is useful for callouts and performance, not for preventing repeat notifications on the same condition.

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

Why it fails: Record-Triggered Flows cannot filter by the user who performed the DML operation. While you can reference $User in a formula, that reflects the running user's context, not the user who triggered the update, and integrations often run as an admin or automated user. This option would not reliably prevent duplicate emails and would also block legitimate user-driven closes.

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

Why it fails: Opportunities are typically created in earlier stages, so a create-only trigger would miss the actual close event. Defaulting Stage to 'Closed Won' at creation would break the sales process and still not address stage changes made later by users. This changes business behavior rather than solving the duplicate notification problem.

Einstein Next Best Action with a recommendation strategy.

Why it fails: Einstein Next Best Action is designed to surface recommendations to users based on strategies and business rules; it does not manage approval workflows, approver assignments, or record locking. It cannot enforce sequential approvals or capture rejection comments as part of an auditable process. This tool is inappropriate for approval routing.

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

Why it fails: While Flow can submit records for approval and orchestrate complex logic, it does not natively provide the approver inbox, rejection-with-comments UI, or multi-step approver routing that Approval Processes deliver out of the box. Building equivalent functionality in Flow would require significant custom work and would not replicate the standard approval interface users expect.

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

Why it fails: A scheduled flow cannot provide real-time approval routing, and using tasks as a proxy for approvals loses the audit trail, rejection comments, and locking behavior of the standard approval engine. Nightly processing also delays the approval cycle, which is unacceptable for time-sensitive discount requests. This approach does not satisfy the routing or rejection requirements.