9.2 Integration Procedures — Action Chaining, Batching & Error Handling
Key Takeaways
- OmniStudio Integration Procedures (IPs) are server-side, declarative orchestrators that execute multiple data actions, calculations, and integrations in a single network round-trip from the client browser.
- Standard IP elements—including Data Mapper Actions, Remote Actions, HTTP Actions, Conditional Blocks, Loop Blocks, and Set Values—provide end-to-end procedural logic without writing custom Apex controllers.
- Robust public sector error handling combines failOnError, failureResponse, and Try-Catch Blocks to deliver graceful degradation when external government dependencies become unavailable.
- Action Chaining (Chain On Step) enables Integration Procedures to overcome synchronous platform governor limits by splitting heavy DML and calculation workloads into chained asynchronous transactions.
- Dual-tier Platform Caching (Session Cache for constituent-specific data and Org Cache for static statutory metadata) drastically reduces database queries and accelerates portal responsiveness during high-traffic civic events.
9.2 Integration Procedures — Action Chaining, Batching & Error Handling
Exam Focus: While OmniScripts and FlexCards deliver dynamic user interfaces, enterprise public sector solutions require a robust, server-side orchestration engine to execute complex business logic, aggregate data from disparate systems, and enforce transaction integrity. On the AP-222 exam, Integration Procedures (IPs) represent the premier architectural pattern for server-side processing. Candidates must understand the single network round-trip principle, master core IP element types, implement defensive error handling with graceful degradation, configure action chaining to overcome governor limits, and deploy platform caching to support massive constituent surges.
Architecture of Integration Procedures: The Server-Side Orchestrator
In client-heavy web architectures, user interfaces frequently make multiple sequential requests to the server: one call to fetch constituent demographics, another to verify identity against an external service, a third to evaluate statutory fee schedules, and a final call to persist records. In a public sector context—where constituents often access portals via mobile devices with constrained cellular bandwidth—this "chatty" communication pattern introduces severe latency, fragile error states, and poor user experience.
OmniStudio Integration Procedures (IPs) solve this architectural vulnerability through the Single Network Round-Trip paradigm. An Integration Procedure is a declarative, server-side process that executes on the Salesforce application tier. The client browser (OmniScript, FlexCard, or external client) makes exactly one remote invocation to the IP. The IP orchestrates all data extraction, external API callouts, business rules evaluations, and database writes server-side, returning a single, curated JSON response back to the client.
+-----------------------------------------------------------------------------------+
| Client-Side Anti-Pattern vs. Integration Procedure Pattern |
+-----------------------------------------------------------------------------------+
| [Client-Side Anti-Pattern (Chatty)]: |
| Browser ──(Network Call 1: Fetch Profile)───> Salesforce Server |
| Browser <───────(JSON Profile Data)────────── Salesforce Server |
| Browser ──(Network Call 2: External DMV)────> Salesforce Server ──> External |
| Browser <───────(JSON DMV Result)──────────── Salesforce Server <── External |
| Browser ──(Network Call 3: Save Record)─────> Salesforce Server |
| Browser <───────(Save Confirmation)────────── Salesforce Server |
| *Result: 3 High-Latency Network Round-Trips; Fragile Mobile Experience* |
| |
| [Integration Procedure Best Practice (Single Round-Trip)]: |
| Browser ──(Single Network Call: Submit Intake)─────────────────┐ |
| ▼ |
| Salesforce Server-Side Execution: |
| [IP Engine] ──> Step 1: Turbo Extract (Constituent Profile) |
| ──> Step 2: HTTP Action (DMV Verification) ──> External Service |
| ──> Step 3: Business Rules Engine (Fee Calculation) |
| ──> Step 4: Data Mapper Load (Save Records) |
| ──> Step 5: Response Action (Return Trimmed JSON) |
| │ |
| Browser <──(Single Curated JSON Response)──────────────────────┘ |
| *Result: 1 Minimal-Latency Network Round-Trip; Maximum Security & Performance* |
+-----------------------------------------------------------------------------------+
Architectural Advantages of Integration Procedures:
- Network Latency Minimization: Consolidates multi-step processes into one server exchange, drastically improving responsiveness on constituent self-service portals.
- Security & Data Sanitization: Intermediate payloads, internal database keys, and sensitive external credentials remain entirely on the server. Only the final, filtered JSON payload defined in the Response Action is sent to the constituent's browser.
- Decoupled Architecture: The presentation layer (OmniScript or FlexCard) is completely decoupled from the data source. If an agency replaces an internal database lookup with an external REST API, only the IP is modified; the frontend UI remains untouched.
- Omni-Channel Reusability: A single Integration Procedure can serve as the backend data engine for an OmniScript, a FlexCard, an Apex controller, a standard Salesforce Flow, an external system via REST API, or an autonomous Agentforce Agent action.
Core Element Types & Declarative Orchestration Mechanics
Integration Procedures provide an extensive catalog of declarative elements that represent procedural programming constructs (loops, conditions, assignments, and calls) within a visual canvas.
| Element Type | Category | Operational Purpose in Public Sector Solutions |
|---|---|---|
| Data Mapper Action | Data Access | Executes a Data Mapper (Turbo Extract, Extract, Transform, or Load) to read or write CRM data. |
| Remote Action | Code Bridge | Invokes a custom Apex class implementing omnistudio.OpenInterface when complex procedural logic or non-standard calculations are required. |
| HTTP Action | Integration | Executes an external REST or SOAP web service callout (e.g., state police background check, GIS zoning lookup). |
| Conditional Block | Logic Flow | Enforces conditional branching (IF / ELSE IF / ELSE) based on constituent input, statutory criteria, or prior action results. |
| Loop Block | Data Iteration | Iterates over arrays of JSON objects (e.g., looping through household members or inspection checklist items). |
| Set Values | Variable State | Declares in-memory variables, merges JSON nodes, and performs algorithmic formula calculations without calling the database. |
| Response Action | Output Control | Halts IP execution and returns a customized, trimmed JSON payload back to the calling client. |
| Try-Catch Block | Fault Tolerance | Encapsulates failure-prone steps (such as external HTTP callouts) to handle timeouts and errors defensively. |
Deep Dive: Flow Control and Data Manipulation Elements
1. Set Values (In-Memory Processing)
The Set Values element is the workhorse for in-memory data manipulation inside an IP. It allows architects to:
- Construct new JSON objects and arrays dynamically;
- Merge separate JSON trees into a unified structure using the
MERGEfunction; - Calculate intermediate mathematical or string expressions using built-in functions (e.g.,
IF(%Age% >= 65, "Senior_Discount", "Standard_Rate")); - Sanitize or mask incoming constituent inputs prior to logging or external transmission.
2. Loop Blocks (Array Iteration)
In public assistance and licensing intake, applications regularly contain repeating arrays—such as lists of household dependents, prior employment records, or commercial vehicle inventories. The Loop Block iterates over a specified JSON array path (e.g., %IntakePayload:HouseholdMembers%).
- Loop Execution: Actions placed inside the Loop Block execute sequentially for each element in the array.
- Performance Warning for AP-222: Placing a Data Mapper Load or Remote Action inside a Loop Block executes DML or SOQL for every single item, rapidly hitting Salesforce governor limits. Instead, architects should use a Data Mapper Transform to reshape the entire array and execute a single, bulkified Data Mapper Load outside the loop.
3. Response Actions (Payload Governance)
By default, if an Integration Procedure reaches the end of its canvas without encountering a Response Action, it returns the entire cumulative server-side JSON execution tree to the caller. This anti-pattern exposes internal system IDs, intermediate API secrets, and unnecessary data over the public network.
- Best Practice: Always terminate an IP with an explicit Response Action.
- Configure the Response JSON Path to return only the specific node required by the UI (e.g.,
%FinalEligibleBenefits%), keeping network payloads tiny and securing internal state.
Action Chaining, Batching, and Governor Limit Management
In complex public sector transactions—such as processing a multi-agency commercial building permit involving zoning lookups, historical landmark checks, environmental risk scoring, and fee calculations—an Integration Procedure can easily approach synchronous Salesforce platform governor limits:
- Synchronous Apex CPU Time Limit: 10,000 milliseconds (10 seconds);
- Total SOQL Queries Issued: 100 queries;
- Total DML Statements Issued: 150 statements.
To overcome these boundaries without resorting to complex asynchronous Apex batch jobs, OmniStudio provides Action Chaining.
+-----------------------------------------------------------------------------------+
| Action Chaining Execution Lifecycle |
+-----------------------------------------------------------------------------------+
| [Transaction 1: Synchronous Execution] |
| Step 1: Extract Applicant Data (SOQL) |
| Step 2: External GIS Callout (HTTP Action) |
| Step 3: Complex Zoning Expression Set (BRE Calculation) |
| *Governor Limits Approaching 8,000ms CPU Threshold* |
| |
| ──> Step 4: Data Mapper Load with [Chain On Step = true] |
| ─────────────────────────────────────────────────────────────────────── |
| • The IP engine halts the synchronous transaction |
| • The engine enqueues a Queueable Apex job containing the remaining steps |
| • A new transaction begins with a FRESH, FULL SET OF GOVERNOR LIMITS! |
| ─────────────────────────────────────────────────────────────────────── |
| |
| [Transaction 2: Asynchronous Chained Execution (Queueable Context)] |
| Step 4: Executes Data Mapper Load (Fresh 150 DML Limit) |
| Step 5: Invokes Document Generation Engine |
| Step 6: Dispatches Notification via Core Notification Engine |
+-----------------------------------------------------------------------------------+
Configuring Action Chaining:
On any major action element (such as a Data Mapper Action, Remote Action, or HTTP Action), the architect can enable the Chain On Step checkbox. When selected:
- If the IP detects that CPU time or query limits are approaching threshold boundaries, or if configured unconditionally, the current transaction is gracefully committed.
- The remaining execution context is serialized and dispatched via Queueable Apex.
- The subsequent action executes in a new asynchronous thread with reset governor limits (e.g., 60,000ms CPU limit and a fresh allocation of 100 SOQL queries).
Additional Execution Options:
- Send Only Additional Input: Restricts the outbound payload of an action to only explicitly defined key-value pairs, preventing the entire cumulative JSON tree from being passed.
- Return Only Additional Output: Captures only the direct output of the action into the context, keeping the memory heap lean.
- Use Queueable Apex for Post: Automatically runs post-commit processing asynchronously, allowing the user interface to receive an instant submission confirmation while heavy processing finishes in the background.
Defensive Error Handling, Failure Responses & Graceful Degradation
Public sector architectures must be resilient. Government websites cannot simply display an unhandled exception or crash when an external state or federal endpoint experiences an outage. AP-222 candidates must master declarative defensive programming within Integration Procedures.
1. The failOnError Property
Every action element in an Integration Procedure includes the failOnError boolean property:
failOnError = true(Default): If the action encounters an error (e.g., an HTTP 500 from an external service, or a DML validation rule failure), the entire Integration Procedure halts immediately, rolls back uncommitted DML transactions, and throws a fatal error.failOnError = false: If the action fails, the IP engine records the error details in the action's execution block (e.g.,%HTTP_DMVCheck:hasErrors% = true), but continues executing subsequent steps.
2. The failureResponse Configuration
When an action fails, returning raw system stack traces or database exceptions to a public portal violates security protocols. The failureResponse property allows architects to define a structured, sanitized JSON error message returned directly to the user interface:
{
"status": "PartialSuccess",
"errorCode": "SVC_TIMEOUT_504",
"userMessage": "The State Identity Verification system is currently experiencing high volume. Your application has been submitted and routed to a specialist for offline verification."
}
3. Graceful Degradation Architectural Pattern
Consider a citizen applying for nutritional assistance. The intake process includes an HTTP Action verifying income against a state Department of Revenue database:
- Set
failOnError = falseon the external HTTP Action. - Place a Conditional Block immediately following the HTTP Action that evaluates:
%HTTP_TaxCheck:hasErrors% == true OR ISBLANK(%HTTP_TaxCheck:IncomeVerificationCode%) - If an error occurred:
- Step 3a: A Set Values action marks the application status as
"Pending Manual Verification". - Step 3b: A Data Mapper Load creates the
IndividualApplicationand inserts a high-priorityTaskfor an eligibility caseworker to manually verify physical pay stubs. - Step 3c: A Response Action informs the citizen that their application was successfully received and is proceeding under standard review.
- Step 3a: A Set Values action marks the application status as
- Outcome: The citizen is not blocked, application data is preserved, and the agency's statutory intake timeline is maintained despite third-party system downtime.
Response Caching Strategies: Session vs. Org Cache
During peak civic events—such as annual tax filing periods, property assessment appeal windows, or public emergency assistance rollouts—government portals experience tens of thousands of concurrent users. Executing database SOQL queries or running Business Rules Engine Expression Sets for identical, static data creates severe database contention and exhausts platform resources.
Integration Procedures provide native integration with Salesforce Platform Cache, enabling architects to cache IP execution outputs across two distinct tiers:
+-----------------------------------------------------------------------------------+
| Platform Cache Architecture in IPs |
+-----------------------------------------------------------------------------------+
| [High-Concurrency Citizen Portal Inbound Requests] |
| │ |
| ▼ |
| [IP Cache Key Evaluation] |
| Is output cached in memory? |
| ├── YES ──> Returns Cached JSON instantly (~5ms) |
| │ (Zero SOQL, Zero CPU, Zero DML) |
| └── NO ──> Executes IP Logic Server-Side |
| Stores result in Platform Cache |
| Returns fresh JSON response |
+-----------------------------------------------------------------------------------+
| Tier 1: Org Cache (Universal) | Tier 2: Session Cache (User-Specific) |
| • Shared across ALL users & guest citizens| • Isolated to individual logged-in user|
| • Static regulatory fee schedules | • In-progress application draft headers|
| • Municipal zoning district rules | • Citizen profile & active enrollments |
| • Standard license requirement checklists | • TTL: Session lifetime or ~15-60 mins |
| • TTL: 300 seconds to 24 hours | |
+-----------------------------------------------------------------------------------+
Configuring Cache in Integration Procedures:
- Cache Type: Select either Org Cache (shared across the entire enterprise) or Session Cache (bound to the specific user session).
- Cache Key Formulation: Define a deterministic, unique cache key utilizing static text and dynamic merge tokens. For example:
LicensingFee_%Jurisdiction%_%LicenseType%If an applicant in "North District" requests a "Commercial Food Vendor" license, the key evaluates toLicensingFee_NorthDistrict_CommercialFoodVendor. Every subsequent constituent requesting that exact same fee calculation receives the cached response instantly from memory without querying the database.
- Time-to-Live (TTL): Specifies how long (in seconds) the cached payload remains valid before expiration (e.g.,
3600for 1 hour, or86400for 24 hours). - Ignore Cache Option: When calling an IP, developers can pass the parameter
ignoreCache = true(e.g., when a caseworker clicks "Force Refresh") to bypass cached data and force a fresh database execution.
💡 Real-World Exam Scenarios & Case Analysis
Scenario 1: Multi-Step Business License Filing with Action Chaining
A state department of agriculture modernizes its industrial processing license intake. The submission process involves extracting applicant history, calling an external federal EPA environmental database, executing a 45-rule Business Rules Engine Expression Set, creating a BusinessLicenseApplication with 12 child regulatory inspection items, and generating an official PDF receipt. During load testing with 500 concurrent applicants, transactions fail with Apex CPU time limit exceeded (10,000ms) errors.
What architectural refactoring must the candidate propose on the AP-222 exam?
- Flawed Approach: Splitting the logic across multiple OmniScript steps requiring the constituent to click 'Next' three separate times. (Poor citizen UX; fails mobile usability standards).
- AP-222 Best Practice: Maintain a single submit button in the OmniScript invoking a master Integration Procedure. In the IP, enable Chain On Step on the Data Mapper Load that creates the child inspection items. Configure the IP to use Queueable Apex for post-processing. The heavy DML and document generation tasks are decoupled into an asynchronous thread with a fresh 60,000ms CPU limit, while the constituent immediately receives a successful submission confirmation.
Scenario 2: Resilient Social Assistance Intake with Graceful Degradation
A county human services agency deploys an emergency rental relief OmniScript. During intake, an IP invokes an external state employment verification API to validate applicant income. During a statewide server failure, the external API throws HTTP 504 Gateway Timeouts, causing the entire county intake portal to fail with generic system error popups. Vulnerable constituents are unable to submit emergency relief applications.
How should the Lead Architect configure the Integration Procedure to resolve this?
- Open the HTTP Action that calls the state API. Uncheck failOnError (setting it to
false). - In the HTTP Action properties, configure a failureResponse that returns
{"verificationStatus": "Offline_Review_Required"}. - Add a Conditional Block that checks if
%HTTP_EmploymentCheck:hasErrors% == true. Inside the block, set application status to"Pending Specialist Verification"and create an intake review task. - Ensure the downstream Data Mapper Load and Response Action execute unconditionally.
- The portal gracefully degrades: constituents complete submissions without interruption, and caseworkers handle verification asynchronously.
A public sector agency experiences severe performance degradation on its constituent self-service portal because an OmniScript executes three separate client-side calls: first querying applicant records via a Data Mapper, then invoking an external state registry via a remote call, and finally persisting records with another Data Mapper. What core architectural benefit does refactoring this process into a single Integration Procedure provide?
An architect is designing an Integration Procedure that performs extensive business validation, executes a heavy Business Rules Engine Expression Set, and inserts hundreds of inspection compliance records for a major industrial facility. During peak processing, the transaction consistently fails with an 'Apex CPU time limit exceeded (10000 ms)' exception on the final Data Mapper Load. What declarative configuration solves this issue within the Integration Procedure?
A municipal government portal receives hundreds of thousands of citizen inquiries regarding static building permit fee schedules and zoning inspection criteria during annual development cycles. To maximize performance and prevent database contention, the architect wants to cache the calculated fee responses across all portal users and unauthenticated guest constituents for 12 hours. Which caching configuration in the Integration Procedure satisfies this requirement?