8.1 OmniScript Architecture, Step Design & Conditional Branching

8.1 OmniScript Architecture, Step Design & Conditional Branching

Exam Focus: OmniScript is the declarative, guided user journey engine of Salesforce Public Sector Solutions (PSS). On the AP-222 exam, candidates must demonstrate thorough mastery of OmniScript's single-page application (SPA) architecture, the complete element palette (Steps, Inputs, Actions, Display elements), conditional execution rules, client-side formulas, real-time error handling, and progressive disclosure principles compliant with public sector accessibility mandates (WCAG 2.1 Level AA).

---

OmniScript Architectural Foundations in Public Sector Solutions

Government agencies deliver critical public services under stringent statutory mandates. Whether filing an application for a professional healthcare license, seeking emergency rental assistance, or submitting complex architectural plans for commercial building permits, constituents must navigate intricate legal disclosures, provide voluminous demographic and financial data, and upload mandatory statutory documentation. Traditional multi-page web forms and legacy paper questionnaires create severe operational bottlenecks: high applicant dropout rates, rampant clerical data-entry errors, and inaccessible citizen interfaces that fail public sector accessibility mandates.

OmniScript addresses these systemic challenges by delivering a declarative, metadata-driven framework for authoring guided digital user journeys. In Public Sector Solutions, OmniScript functions as the premier constituent intake layer across both public-facing digital self-service channels and internal agency workspaces:

• Single-Page Application (SPA) Runtime: OmniScript compiles directly into standard Lightning Web Components (LWC). It operates entirely as a reactive single-page application within the constituent's browser. Rather than executing full-page reloads between steps, OmniScript updates its visual presentation dynamically while maintaining an in-memory transactional state. This architecture delivers consumer-grade responsiveness, critical for low-bandwidth rural constituents and mobile users.
• The Unified Data JSON Tree: At runtime, an OmniScript maintains a centralized, hierarchical JSON document known as the OmniScript Data JSON. Every element on the canvas—whether an applicant input field, an automated formula, a prefilled demographic node, or an external API response—reads from and mutates this single state tree. As constituents advance through steps, data flows seamlessly between visual UI elements and backend services via standardized JSON path addressing.
• Multi-Channel Deployment Flexibility: A single compiled OmniScript can be deployed across multiple digital touchpoints without modifying underlying business logic. It can be embedded within public-facing Experience Cloud LWR (Lightning Web Runtime) or Aura sites for unauthenticated guest citizens or authenticated portal users, embedded directly on Lightning Record Pages within the internal Public Sector Service Console for intake caseworkers, launched dynamically from FlexCard actions, or invoked via standalone URL links.

---

The OmniScript Element Palette: Categories and Public Sector Applications

The OmniScript designer organizes functional building blocks into distinct categories within its element palette. Implementation architects must understand the precise role, data behavior, and public sector application of each category.

1. Step Design and Navigation Governance

A Step element represents an individual visual screen in the constituent journey. Public sector intake flows often group 20 to 50 data points into 4 to 7 coherent steps (e.g., 1. Identity -> 2. Business Entity -> 3. Location Details -> 4. Required Uploads -> 5. Fee Review & Sign).

Key Step configuration properties include:

• Validation Enforcement: By default, clicking the "Next" button triggers client-side validation across all input elements within the current step. The user cannot advance until all required fields and regex patterns are satisfied.
• Step Chart & Progress Indicators: The Step Chart visually guides the constituent through milestones, displaying completed, active, and upcoming phases to reduce cognitive load.
• Cancel and Save Options: Architects can enable standard "Cancel" and "Save for Later" buttons directly within step properties, allowing constituents to pause multi-hour applications without losing progress.

2. Input Elements and Data Type Integrity

Input elements map constituent responses directly into key-value pairs in the OmniScript Data JSON. For example, placing a Text element named ApplicantSSN inside a step named IdentityVerification produces the following JSON structure:

{
  "IdentityVerification": {
    "ApplicantSSN": "999-00-1234"
  }
}

Public sector architectures leverage specialized input controls:

• Input Masks & Regex Patterns: Enforce standard formats for Federal Employer Identification Numbers (^\d{2}-\d{7}$), Social Security Numbers, and state professional registration codes, preventing malformed submissions.
• Select (Picklists) & Radio Groups: Bound to global value sets or populated dynamically via Integration Procedures to reflect statutory license categories.
• File Upload: Integrates natively with Salesforce ContentVersion and the PSS DocumentChecklist framework, allowing constituents to submit PDF blueprints, tax returns, and identity cards directly from mobile devices.

3. Action Elements: Database & Orchestration Engines

Action elements provide the processing power behind the user interface:

• Integration Procedure (IP) Action [Gold Standard]: The architectural best practice for executing server-side logic. An IP Action invokes an OmniStudio Integration Procedure that can batch multiple database operations, execute Business Rules Engine (BRE) expression sets, call external agency databases via Named Credentials, and trim JSON payloads in a single optimized server call.
• Data Mapper Action (Extract / Post): Direct interaction with Salesforce records. While functional for simple single-object queries, architects prefer IP Actions for enterprise applications to avoid chatty, un-batched client-server interactions.
• Navigate Action: Placed on the final step or triggered conditionally to redirect the applicant to their generated BusinessLicenseApplication record, an application confirmation dashboard, or an external payment gateway.
• Set Values Action: Modifies or injects data directly into the Data JSON on the client side without contacting the server (e.g., setting a default application status of Draft or combining first and last names into a full name node).
• Set Errors Action: Evaluates JSON conditions and injects explicit, custom validation errors onto specific elements or steps, halting progress if legal criteria are violated.

4. Display and Grouping: Edit Block for Repeating Structures

A critical public sector requirement is capturing repeating structures—such as listing all corporate officers for a commercial liquor license, detailing household members for SNAP benefits, or registering multiple fleet vehicles.

• The Edit Block Element: Renders an inline repeating table or card set where constituents can add, edit, or remove line items dynamically.
• Each entry in an Edit Block produces an array of JSON objects within the OmniScript Data JSON (e.g., "Officers": [ {"Name": "Jane Doe", "Role": "President"}, {"Name": "John Smith", "Role": "Treasurer"} ]), which can later be mapped directly into child records using a Data Mapper Load or Integration Procedure.

---

Conditional Execution, Branching & Progressive Disclosure

Public statutory forms are notorious for conditional complexity. For example, a restaurant permit application requires health department disclosures only if commercial food preparation occurs on-premise; if the establishment serves alcohol, state liquor board disclosures and background affidavits become mandatory.

                    [Applicant Type Question]
                                |
        +-----------------------+-----------------------+
        |                                               |
 [Sole Proprietorship]                         [Commercial Entity]
        |                                               |
  (Direct to SSN &                               (Branch to Corporate
   Home Address Steps)                            Structure, EIN & Officer Steps)
        |                                               |
        +-----------------------+-----------------------+
                                |
                    [Zoning & Physical Facility]
                                |
                    [Hazardous Materials?]
                     /                  \
                  (Yes)                 (No)
                   /                      \
        [Show EPA Containment]       [Skip to Review]

Mechanics of Conditional View Properties

OmniScript manages branching dynamically via Conditional View properties available on virtually every canvas element, including entire Steps, Blocks, Inputs, and Actions:

1. Evaluation Engine: Conditional rules are evaluated purely client-side by the LWC runtime against the live Data JSON tree. No server round-trip or Apex execution is required.
2. Logical Operators: Rules support comparisons (=, !=, <, >, <=, >=, LIKE), boolean flags, and nested logic using AND / OR groups.
3. Dynamic Step Skipping: When an entire Step has a Conditional View rule that evaluates to false, the OmniScript runtime completely removes that step from the execution pipeline and hides it from the Step Chart. The user smoothly transitions from Step 1 to Step 3 without ever seeing Step 2.
4. Dynamic Element Display: Within a single step, input fields or informational blocks remain hidden until their triggering condition is met. For instance, the field "Underground Storage Tank Capacity" is set to display only when "HasUndergroundTanks" == true.

Progressive Disclosure Principles in Public Administration

Progressive disclosure is an interaction design paradigm where complex information and choices are presented only as needed. In government applications, progressive disclosure yields measurable operational benefits:

• Minimizes Cognitive Overload: Prevents citizens from abandoning forms when confronted by 100+ visible questions, 80% of which do not apply to their specific statutory classification.
• Prevents Dirty Data: By conditionally hiding irrelevant fields, the system prevents applicants from entering conflicting or erroneous data in categories they do not qualify for.
• Maintains Lean JSON Payloads: Elements hidden by conditional logic do not submit values, keeping outgoing data payloads lean and clean.

---

Formulas, Validation & Real-Time Error Handling

Ensuring data accuracy before submission is essential in public sector intake, where administrative processing costs soar when incomplete or inaccurate filings enter agency review queues.

Formula Elements: Real-Time Client-Side Calculation

The Formula element evaluates expressions client-side in real time as the user types. Formulas utilize OmniStudio expression syntax to perform mathematical, string manipulation, and logical operations:

• Statutory Fee Computation: Calculate estimated permit fees on the fly: IF(%SquareFootage% > 5000, 500 + ((%SquareFootage% - 5000) * 0.15), 500)
• Age Verification: Derive applicant age from a birthdate input: AGE(%ApplicantDOB%)
• Dynamic Strings & Indicators: Generate composite strings or eligibility status flags that drive downstream conditional view logic.

Because formulas recalculate instantaneously in the browser, they provide immediate transparency to constituents regarding estimated costs and statutory prerequisites.

Multi-Tiered Validation Architecture

OmniScript enforces validation across three distinct architectural layers:

1. Element-Level Input Validation: Enforced via declarative properties on the input element itself (e.g., Required, Min Length, Max Length, Pattern). If a required field is empty or fails regex, the input automatically highlights in red with a standard or custom error message.
2. Custom Error Handling with Set Errors: When validation rules depend on complex multi-field cross-validation (e.g., "If Permit Type is Commercial, Square Footage must be greater than 1,000 and Architect License Number must not be blank"), a Set Errors action element can be placed on step transition. If the formula evaluates to an invalid state, Set Errors halts step progression and binds an explicit, human-readable error message to the target field.
3. Messaging Elements: Declarative UI components that display dynamic banner messages (Informational, Warning, Success, Requirement Error) directly on the screen based on conditional rules. For example, if an applicant enters an income figure that exceeds statutory eligibility thresholds, a Warning Banner immediately notifies the constituent of potential disqualification before they spend time completing subsequent steps.

---

Constituent UX & WCAG 2.1 Accessibility Mandates

Public sector digital systems are subject to strict legal accessibility requirements, such as Section 508 of the Rehabilitation Act in the United States, ADA Title II guidelines, and global standards based on the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA.

Accessible Digital Experience Principles

• Native Semantic HTML & ARIA: OmniScript LWCs generate semantic HTML5 elements with appropriate WAI-ARIA roles, states, and properties. Screen readers (such as JAWS, NVDA, and VoiceOver) accurately announce form controls, validation errors, and step transitions.
• Keyboard Navigation: All OmniScript interactive elements—including dropdowns, radio groups, date pickers, and step navigation buttons—must be fully operable using only a keyboard (Tab, Shift+Tab, Enter, Space, Arrow keys).
• High-Contrast Styling and Clear Typography: Public agency implementations must configure OmniScript styling using the Salesforce Lightning Design System (SLDS) or custom Newport Design System (NDS) themes that guarantee a minimum contrast ratio of 4.5:1 for standard text and 3:1 for large text and UI components.
• Contextual Help and Error Recovery: Public sector forms must provide clear, plain-language instructional labels, persistent help tooltips, and constructive error messages that describe exactly how to remediate an invalid entry rather than displaying cryptic system codes.
• Multi-Language Localization: OmniScript natively supports localization through the Salesforce Translation Workbench and Custom Labels. By defining labels in multiple languages, the OmniScript dynamically renders in the constituent's preferred language (e.g., Spanish, Cantonese, Vietnamese) based on browser locale or portal language selection, without duplicating the underlying OmniScript flow.

---

OmniScript vs. Salesforce Screen Flow: Public Sector Comparison

Candidates frequently encounter exam questions requiring them to justify choosing OmniScript over standard Salesforce Screen Flow for public sector intake.

---

💡 Real-World AP-222 Exam Scenarios & Case Analysis

Scenario 1: State Occupational Licensing Board Multi-Tier Intake

A state occupational licensing board requires an online intake process for electrical contractor licenses. The application requires individuals applying as Sole Proprietors to provide their SSN, personal background history, and proof of master electrician certification. Businesses applying as Corporations or LLCs must skip personal background questions, provide their Federal EIN, upload Articles of Incorporation, and enter a repeating list of corporate officers. Additionally, the application must compute an estimated statutory fee based on company size and provide a progress indicator compliant with WCAG 2.1 AA.

How should the Lead Architect design the solution using OmniStudio?

• Architecture: Deploy a responsive OmniScript on the public-facing Experience Cloud site.
• Step & Branching Design:
  • Step 1 captures ApplicantType (Sole Proprietor vs. Corporation/LLC).
  • Step 2 (SoleProprietorDetails) is configured with a Conditional View rule (ApplicantType == 'Sole Proprietor').
  • Step 3 (CorporateDetails) is configured with a Conditional View rule (ApplicantType == 'Corporation/LLC'), containing an Edit Block element to capture repeating corporate officers.
• Fee Calculation: Utilize a client-side Formula element to evaluate the statutory fee schedule instantaneously based on contractor classification.
• Accessibility & Submission: Leverage standard SLDS accessibility-compliant input controls, and trigger an Integration Procedure Action on the final step to create the BusinessLicenseApplication, link the RegulatoryAuthorizationType, and insert officer records in a single database transaction.

Scenario 2: Municipal Special Event Permitting with Safety Validations

A city government receives 10,000 special event permit applications annually. The municipal intake form must dynamically prompt for temporary food establishment permits only if the event indicates on-site cooking. If expected attendance exceeds 2,500 people, the form must mandate a crowd management safety plan upload and require the applicant to acknowledge public safety fees before advancing to the payment step. Clerical staff report that applicants frequently submit incomplete files.

What OmniScript configuration guarantees data integrity and prevents premature submission?

• Place a Checkbox element for "WillFoodBeServed" and a Number element for "EstimatedAttendance" on the Event Overview step.
• Configure a Block containing health inspection upload fields with a Conditional View rule set to "WillFoodBeServed" == true.
• Place a File upload element for the CrowdManagementPlan with a Conditional View rule set to "EstimatedAttendance" > 2500 and mark the element as Required.
• Implement a Set Errors Action prior to the final review step that checks whether attendance exceeds 2,500 and the safety plan file ID is null; if true, the action blocks navigation and displays an explicit statutory error banner instructing the applicant to attach the safety document.