Process Automation And Logic practice questions

System validation rules run after Before Triggers but before custom validation rules.

Why it fails: System validation rules actually execute *before* Before Triggers during an insert operation, meaning this sequence reverses the actual Salesforce order of execution. This option is tempting because developers frequently rely on Before Triggers to sanitise or manipulate incoming field data prior to data checks, making it logical to assume system validations wait for those modifications to complete. This alternative sequence would apply if Salesforce evaluated raw field formats and system-level constraints only after custom business logic had finished executing its initial pass on the record.

Before Triggers execute before system validation rules.

Why it fails: System validation rules run before insert triggers fire, meaning that stating triggers execute first reverses the actual Salesforce order of execution for these lifecycle steps. This sequence appears plausible because developers frequently use before triggers to modify field values prior to validation, creating the misconception that these code blocks process first to prepare the record. In alternative architectural contexts, custom validation logic often relies on pre-processed data states, leading to the false assumption that database constraints similarly wait for trigger completion.

Before Triggers and system validation rules run concurrently.

Why it fails: Executing these distinct processing phases concurrently is fundamentally flawed because Salesforce enforces a strictly sequential order of execution during record saves. The platform must complete all before-save triggers before evaluating system validation rules to ensure data is thoroughly modified and sanitised before integrity checks occur. This concurrent execution model sounds tempting when developers reason about multi-threaded asynchronous processing or independent transaction branches, which might operate simultaneously in other architectures to maximise throughput. However, synchronous record-save transactions rely entirely on a linear sequence where trigger modifications directly influence the subsequent validation outcomes.

After Insert

Why it fails: After Insert triggers run subsequent to the database transaction saving the record, meaning any field modifications to the same record would necessitate a costly and recursive DML statement via `update`, leading to potential infinite loops. This event context appears tempting because developers frequently utilise insert operations to coordinate related child records or perform post-processing tasks; it would represent the correct choice if the requirement mandated interacting with system-generated fields like IDs or timestamps on newly created records that are only accessible post-commit.

After Update

Why it fails: Using an after-update trigger fails this scenario because the record has already been committed to the database, meaning that any field modifications attempted on the same record require an explicit DML statement and will throw a runtime exception. This option is tempting because developers frequently use update triggers to handle post-processing logic; it would be the correct choice when you need to perform actions on related records or external systems after the database transaction has successfully completed and you possess the final, read-only record IDs.

Before Undelete

Why it fails: Undelete triggers execute when records are restored from the Recycle Bin, failing to fire during standard record creation or updates, which makes them entirely inapplicable to the initial save lifecycle described in the prompt. Developers might mistakenly consider this event because it is a "before" trigger context capable of mutating record fields without explicit DML statements, meaning it *would* be the correct choice if the business requirement specifically demanded logic execution prior to recovering previously deleted records.

60,000 milliseconds

Why it fails: Sixty thousand milliseconds is incorrect because it exceeds the synchronous CPU time boundary enforced in Developer Edition environments, which restricts synchronous transactions to 10,000 milliseconds. This value is tempting because it represents the CPU time limit allocated for asynchronous transactions, such as future methods, batch Apex, or queueable jobs, which run with a significantly higher execution ceiling to accommodate longer-running, background processing tasks.

120,000 milliseconds

Why it fails: The limit of 120,000 milliseconds applies specifically to asynchronous Apex transactions, such as queueable, batch, or scheduled jobs executed via flex queue processing. Developers frequently confuse these limits because asynchronous contexts are granted double the execution duration of synchronous ones to accommodate heavier data volumes. However, the scenario strictly specifies a synchronous transaction executed in a developer edition org, where the governor limit is restricted to 10,000 milliseconds to prevent UI thread lockups and maintain responsiveness.

5,000 milliseconds

Why it fails: Synchronous Apex transactions in a Developer Edition org are capped at 10,000 milliseconds, so 5,000 ms understates the governor limit. It is tempting because 5,000 ms is the separate limit for asynchronous Apex transactions, which would be the correct figure had the question asked about future or queueable methods.

Database.allowsCallouts

Why it fails: `Database.allowsCallouts` enables HTTP callouts within batch Apex, but it provides no mechanism for handling record-level exceptions or maintaining transaction continuity during failures. Developers often confuse this interface with error-handling configurations because it modifies the execution context of the batch class. It is the correct choice only when the batch logic must perform external web service requests, as these are restricted by default in asynchronous Apex processes, but it remains irrelevant to the requirement of fault tolerance for individual record processing.

System.abortJob()

Why it fails: Calling `System.abortJob()` terminates the entire batch process immediately, which contradicts the requirement to allow processing to continue for the remaining records. Developers often consider this method when they need to halt execution upon encountering a critical, non-recoverable error that invalidates the entire batch run. However, it lacks the granular error-handling capability required to isolate faulty records while maintaining the operational status of the rest of the job, making it unsuitable for partial failure scenarios.

Database.rollback()

Why it fails: Invoking `Database.rollback()` within a batch execution context reverts all database operations performed within a transaction to a savepoint, effectively undoing the processing of the entire chunk rather than allowing successful records to persist. This method serves to maintain atomicity when performing complex multi-step operations where partial success is unacceptable. It is a valid mechanism for ensuring data integrity during transactional failures, but it contradicts the requirement to continue processing subsequent records after an exception occurs.

Unlimited

Why it fails: Chaining is strictly capped to prevent infinite loops.

1

Why it fails: Chaining a Queueable job that implements `Database.AllowsCallouts` is permitted up to 50 times in an execution sequence, making a limit of one incorrect because it would prematurely halt the asynchronous processing chain. This single-job limitation is tempting because it reflects the stricter constraints applied to asynchronous callouts in older paradigms, or synchronous governor limits, where subsequent executions are restricted to prevent infinite loops. A limit of one would apply if you were restricted to a single initial asynchronous execution without further self-perpetuating chaining.

50

Why it fails: 50 exceeds the queueable chain limit.

The transaction is rolled back due to governor limits.

Why it fails: It throws an sObject exception rather than a governor limit exception.

The trigger fires infinitely without stopping.

Why it fails: Salesforce stops recursion after a specific depth limit, but here an sObject exception occurs first.

The record updates successfully without issues.

Why it fails: Modifying `Trigger.new` records and executing an explicit DML update statement within an `after` trigger causes a runtime system exception because records in `Trigger.new` are strictly read-only during after triggers. This approach often tempts developers because it mirrors the standard logic used in `before` triggers, where field values on `Trigger.new` are modified in-memory without a DML statement to persist changes before the database commit. In a `before` trigger, mutating `Trigger.new` directly is the correct design pattern for updating field values prior to insertion, whereas `after` triggers require querying records or using `before` contexts for such updates.

Trigger.operationType

Why it fails: `Trigger.operationType` exposes the system enumeration representing the exact context execution phase, such as `System.TriggerOperation.AFTER_UPDATE`, allowing developers to route execution logic cleanly within a dispatcher pattern. However, it fails in this scenario because it only reveals the lifecycle phase rather than providing record collections or storing field state transitions. It becomes tempting when designing multi-event handler frameworks that need to inspect the running trigger context dynamically, where it serves as the correct choice for branching based on execution events.

Trigger.size

Why it fails: `Trigger.size` evaluates to an integer representing the total number of records in the current batch invocation, making it tempting when developers need to conditionally execute logic based on bulk volume thresholds. However, it fails in this scenario because it provides a simple count rather than a collection of record instances, completely lacking access to the map of previous field values stored in `Trigger.oldMap`. While useful for logging, performance telemetry, or bypassing execution blocks when bulk limits are reached, it lacks the relational record data required for field-by-field comparisons.

Trigger.new and Trigger.old

Why it fails: Trigger.new and Trigger.old both satisfy the constraint for an after update trigger by providing the necessary collections to compare prior and current field states. Trigger.new contains the most up-to-date sObject versions, whereas Trigger.old holds the pre-update versions of the same records. Developers use a map structure matching IDs to these records, typically instantiated as Trigger.newMap and Trigger.oldMap, to efficiently evaluate field changes side by side during execution.

Concurrently with workflow rules.

Why it fails: Workflow rules run after assignment rules.

After all triggers have completely finished.

Why it fails: Assignment rules run before standard after-triggers execute, meaning they cannot wait until all triggers have completely finished. This option describes the timing for post-processing mechanisms like escalation rules or auto-response rules that indeed evaluate at the very end of the save pipeline. It is tempting because developers often assume automation runs sequentially from database commit outward, and standard after-triggers are indeed appropriate when you need to inspect final database IDs and system-generated field values before performing external integrations.

Before any triggers execute.

Why it fails: Triggers execute before assignment rules.

Future methods return an AsyncApexJob ID immediately upon invocation.

Why it fails: Future methods cannot be used here because they return `void`, meaning they do not provide an `AsyncApexJob` ID upon invocation to track execution. This feature is tempting because queueable Apex does return an `AsyncApexJob` ID via the `System.enqueueJob` method, making future methods appear similarly trackable. Developers would correctly choose queueable Apex when they require programmatic job monitoring and chaining capabilities for asynchronous processing.

Future methods can be called synchronously from within another future method.

Why it fails: Future methods cannot be invoked synchronously from another future method because the Salesforce platform explicitly prevents chained asynchronous execution to avoid infinite loops and recursive trigger degradation. Developers often attempt this pattern when trying to sequence asynchronous operations or delegate additional callout logic following a prior asynchronous process. Chaining is only legally achieved by transitioning to Queueable Apex, which natively supports `System.enqueueJob` from within another executing job, making Queueable the correct architectural choice for sequential asynchronous execution.

Queueable

Why it fails: Queueable is a separate asynchronous interface.

InstallHandler

Why it fails: InstallHandler is for managed package post-install scripts.

Batch Apex automatically rolls back the entire 50-million record job if a single record in one chunk fails.

Why it fails: Batch jobs fail per chunk unless allOrNone is handled or partial saves are configured; the entire job doesn't necessarily roll back unless aborted.

Database.AllowsCallouts

Why it fails: `Database.AllowsCallouts` is designed to permit outbound web service requests to external systems during asynchronous transactions, making it tempting if the nightly processing job needs to synchronise data with a third-party API. However, implementing this interface only grants permission for HTTP callouts; it does not provide the batch processing framework required to execute the job across multiple objects or handle governor limits when managing large volumes of records. To process extensive data sets asynchronously without hitting resource limits, the class must implement `Database.Batchable`.

Batchable

Why it fails: Batchable is used for chunking large datasets, but the entry point for scheduling is Schedulable.

Queueable

Why it fails: Queueable is for asynchronous execution, but scheduling requires Schedulable.

Workflow Rule

Why it fails: Workflow rules are retired automation tools that cannot execute complex looping, custom exception handling, or traverse parent-to-child relationships involving up to 10,000 records. They appear tempting because they are designed for declarative field updates and basic cross-object field propagation down a master-detail relationship. In a different scenario where the requirement is limited to updating a simple field on a parent record when a child is modified—without looping, error handling, or volume constraints—a declarative workflow rule would be the correct choice.

Record-Triggered Flow

Why it fails: While flows can handle many updates, very complex logic with heavy custom iteration and exception handling often relies on Apex.

Process Builder

Why it fails: Process Builder lacks the capacity to handle up to 10,000 related records efficiently due to governor limits on SOQL queries and DML operations, and it does not support advanced programmatic features such as complex looping and robust exception handling. It is tempting because it provides a declarative interface for automating record updates triggered by parent field changes, making it the correct choice for straightforward, low-volume automation where complex iterative logic and granular error management are not required.

System.AsyncException due to calling a future method from another asynchronous context or batch

Why it fails: Future methods cannot call other future methods or be called from batch/scheduled contexts in certain nested ways.

System.LimitException due to query row limits

Why it fails: Query row limit exceptions occur when SOQL statements retrieve more than the permitted 50,000 records within a single transaction, driven by massive data volumes or unselective queries. Developers often suspect query limits when asynchronous methods process large datasets alongside synchronous trigger operations. However, this exception is irrelevant here because the transactional conflict stems from mixing DML operations and asynchronous future method calls that reference the same records, rather than exceeding data retrieval volumes.

System.NullPointerException

Why it fails: Passing a live record reference into a future method is tempting because developers frequently need to hand context to asynchronous jobs, and `NullPointerException` typically arises when attempting to dereference uninitialised memory or missing variable assignments in standard code paths. However, this exception is not triggered here because Salesforce serialises the record IDs before queuing the asynchronous execution. The actual failure stems from data locking and transaction isolation constraints caused by mixed DML operations rather than unassigned pointer references.

Trigger.old

Why it fails: `Trigger.old` is read-only, which makes it incapable of modifying field values in any context, failing the requirement to alter record data before DML operations commit. Developers often find this option tempting because it provides access to the pre-update or pre-deletion state of records, making it the correct choice when you need to validate changes or compare previous field values against `Trigger.new` during update and delete events.

Trigger.oldMap

Why it fails: `Trigger.oldMap` is unavailable because it returns a read-only map of records prior to the current state change, preventing any field modifications. Developers are often tempted to use this variable because it provides efficient ID-to-record lookup capabilities for existing records. It would be the correct choice when you need to compare previous field values against new values (`Trigger.new`) during update triggers, or when referencing pre-existing record states in delete triggers.

Trigger.newMap

Why it fails: `Trigger.newMap` is a read-only collection of sObject records and cannot be used to modify field values because it is designed purely for lookup purposes. Developers are tempted to use it because it provides convenient map-based access to record IDs and their corresponding updated states, making it the correct choice in *after* triggers where you need to evaluate current record values against `Trigger.oldMap` to detect specific field changes or relate child records.

200 locs

Why it fails: The limit of 200 refers to the asynchronous governor limit for the total number of SOQL queries issued in a single transaction when executed via batch or future methods, rather than the synchronous limit of 100. This figure is tempting because developers frequently encounter it when scaling database operations inside queued or scheduled background jobs. It would be the correct choice if the question specifically asked about the maximum query allowance for an asynchronous context executed by `@future` or `Queueable` implementations.

200

Why it fails: 200 is not the SOQL query limit (though it is a common batch size or trigger batch limit).

50

Why it fails: The synchronous governor limit for total SOQL queries issued in a single Apex transaction is actually 100, meaning 50 falls well below the enforced runtime boundary and would prematurely terminate valid processing. Developers often confuse this with the asynchronous limit for batch execution or specific sub-transaction caps, where lower thresholds govern restricted execution contexts. While 50 might appear as a reasonable threshold for conservative resource management, Salesforce enforces a maximum of 100 synchronous queries per transaction to balance multi-tenant performance and resource sharing.

Increase the batch size to the maximum of 2,000 to complete faster.

Why it fails: Processing a larger batch size of 2,000 records holds parent records and related parent locks for longer periods during each transaction, which severely exacerbates concurrency bottlenecks and increases the likelihood of conflicting updates failing. Although this approach is tempting because increasing throughput is the standard method to accelerate overall execution time when optimising batch jobs that process independent records, it directly accelerates failure rates when concurrent processes are targeting the same parent records.

Convert the batch job into a synchronous trigger.

Why it fails: Synchronous triggers execute inline within the exact transaction that initiates a DML operation, which would immediately bottleneck high-volume data loads and severely exacerbate record locking contention rather than alleviating it. This approach is typically utilised for enforcing real-time data validation and cascading field updates directly on individual records in response to user interface actions or API calls. While it correctly ensures immediate transactional consistency for single-record user interactions, it fails completely when attempting to asynchronously process millions of records in scheduled batches where concurrent updates naturally collide.

Disable all validation rules on the object permanently.

Why it fails: Disabling validation rules permanently removes data-integrity enforcement across the org and does nothing to resolve lock contention between concurrent updates. Validation rules govern data quality, not record locking; the correct approach retries failed records or reduces batch scope.

Sending a standard email notification template when a status changes.

Why it fails: Sending an outbound email template natively utilises Salesforce's declarative Action framework, which is readily accessible within Record-Triggered Flows via the Send Email core action. Flow handles asynchronous communication tasks cleanly through built-in connectors without requiring custom code. Developers often find declarative email actions tempting for straightforward notification requirements because they abstract away messaging boilerplate, making them the correct choice for standard template delivery where complex payload transformation or synchronous exception handling is unnecessary.

Updating a simple custom field on the same record before it is saved.

Why it fails: Before-save record updates execute without requiring a DML statement inside a fast field updates flow, making declarative automation the superior technical mechanism for modifying fields on the host record itself. Developers are often tempted to deploy code for this logic because Apex Triggers handle record manipulation natively through trigger context variables. Such an implementation would indeed function correctly for basic field assignments, yet it bypasses the optimised declarative execution pipeline specifically engineered to process before-save modifications without additional system overhead.

Creating a task for a lead owner upon lead assignment.

Why it fails: Automating record creation tasks like assigning a follow-up action to a lead owner is easily accomplished using declarative tools such as Record-Triggered Flows, making programmatic code unnecessary here. Developers are often tempted to use Apex triggers for assignment logic because of historical familiarity with older automation frameworks and complex trigger handler patterns. However, this scenario would be the correct choice for an Apex trigger only if the task creation required executing complex asynchronous callouts, processing extremely high-volume bulk operations that exceed declarative governor limits, or integrating deeply with legacy external systems where declarative tools lack the necessary extensibility.

500 future methods per Apex transaction

Why it fails: 500 exceeds the future call limit.

10 future methods per Apex transaction

Why it fails: 10 is incorrect.

100 future methods per Apex transaction

Why it fails: 100 is the SOQL query limit, not future method calls.

Triggers cannot be defined on standard objects, only custom objects.

Why it fails: Apex triggers can indeed be defined on standard objects such as Account and Contact, as well as custom objects. Developers frequently need to automate business logic and enforce data validation rules upon DML operations for standard platform objects. This statement appears plausible because standard objects initially feel distinct from custom objects within the schema, leading to the false assumption that programmatic automation is restricted to user-defined data structures.

Triggers cannot process more than 200 records in a single batch chunk.

Why it fails: Trigger batch size is typically 200, but platform architecture can pass collections in batch contexts; however, the primary limitation option is correct regarding callouts, stack depth, and DML limits.