Building Omnistudio Omniscript

building-omnistudio-omniscript: OmniStudio OmniScript Creation and Validation

Expert OmniStudio OmniScript builder for declarative, step-based guided digital experiences. OmniScripts are the OmniStudio analog of Screen Flows: multi-step, interactive processes that collect input, orchestrate server-side logic (Integration Procedures, DataRaptors), and present results to the user — all without code.

Quick Reference

Scoring: 120 points across 6 categories. Thresholds: ✅ 90+ (Deploy) | ⚠️ 67-89 (Review) | ❌ <67 (Block - fix required)

---

Scope

• In scope: Creating OmniScripts from requirements, element selection and PropertySetConfig design, dependency analysis (Integration Procedures, DataRaptors), data flow tracing, 120-point validation scoring, deployment and activation
• Out of scope: Building FlexCards (use building-omnistudio-flexcard), creating Integration Procedures directly (use building-omnistudio-integration-procedure), mapping full dependency trees (use analyzing-omnistudio-dependencies), deploying metadata to org (use deploying-metadata)

---

Required Inputs

Gather these before building:

---

Core Responsibilities

1. OmniScript Generation: Create well-structured OmniScripts from requirements, selecting appropriate element types for each step 2. Element Design: Configure PropertySetConfig JSON for each element with correct data binding, validation, and conditional logic 3. Dependency Analysis: Map all references to Integration Procedures, DataRaptors, and embedded OmniScripts before deployment 4. Data Flow Analysis: Trace data through the OmniScript JSON structure — from prefill through user input to final save actions

---

CRITICAL: Orchestration Order

analyzing-omnistudio-dependencies → building-omnistudio-datamapper → building-omnistudio-integration-procedure → building-omnistudio-omniscript → building-omnistudio-flexcard (you are here: building-omnistudio-omniscript)

OmniScripts consume Integration Procedures and DataRaptors. Build those FIRST. FlexCards may launch OmniScripts — build FlexCards AFTER. Use analyzing-omnistudio-dependencies to map the full dependency tree before starting.

---

Key Insights

---

Workflow Design (5-Phase Pattern)

Phase 1: Requirements Gathering

Before building, evaluate alternatives: OmniScripts are best for complex, multi-step guided processes. For simple single-screen data entry, consider Screen Flows. For data display without interaction, consider FlexCards.

Ask the user to gather:

• Type: The process category (e.g., ServiceRequest, Enrollment, ClaimSubmission)
• SubType: The specific variation (e.g., NewCase, UpdateAddress, FileAppeal)
• Language: Typically English unless multi-language support is required
• Purpose: What business process this OmniScript guides the user through
• Target org: Org alias for deployment
• Data sources: Which objects/APIs need to be queried or updated

Then: Check existing OmniScripts to avoid duplication, identify reusable Integration Procedures or DataRaptors, and map the dependency chain.

Phase 2: Design & Element Selection

Design each step and select element types appropriate to the interaction pattern.

Container Elements

Input Elements

Display Elements

Action Elements

Logic Elements

Phase 3: Generation & Validation

Run scripts/check-duplicate-omniscript.sh <Type> <SubType> <Language> <org> to verify no duplicate Type/SubType/Language exists.

Build the OmniScript: 1. Create the OmniProcess record with Type, SubType, Language, and OmniProcessType='OmniScript' 2. Create OmniProcessElement child records for each Step (Level=0) 3. Create OmniProcessElement child records for each element within Steps (Level=1+, ordered by Order field) 4. Configure PropertySetConfig JSON for each element 5. Wire action elements to their Integration Procedures / DataRaptors

Validation (STRICT MODE):

• BLOCK: Missing Type/SubType/Language, circular OmniScript embedding, broken IP/DataRaptor references, missing required PropertySetConfig fields
• WARN: Steps with no elements, input elements without validation, missing error handling on actions, unused data paths, deeply nested elements (>4 levels)

Validation Report Format (6-Category Scoring 0-120):

Score: 102/120 ---- Very Good
-- Design & Structure: 22/25 (88%)
-- Data Integration: 18/20 (90%)
-- Error Handling: 17/20 (85%)
-- Performance: 18/20 (90%)
-- User Experience: 17/20 (85%)
-- Security: 10/15 (67%)

Phase 4: Deployment

1. Prerequisites: Verify org auth (sf org display -o <org>). Confirm all referenced DataRaptors and Integration Procedures are active in the target org. 2. Deploy all dependencies first: DataRaptors, Integration Procedures, referenced OmniScripts. 3. Run scripts/deploy-omniscript.sh <Name> <Type> <SubType> <org> — this deploys the OmniScript and verifies activation. If deployment fails, the script outputs recovery instructions (deactivate and delete the partial record, then retry). 4. Activate the OmniScript version after successful deployment if not auto-activated.

Phase 5: Testing

Walk through all paths with various data scenarios:

• Happy path: Complete all steps with valid data, verify submission
• Validation testing: Submit invalid data at each input, verify error messages
• Conditional testing: Exercise all conditional blocks and verify show/hide logic
• Data prefill: Verify DataRaptor Extract Actions populate elements correctly
• Save for later: Test resume functionality if enabled
• Navigation: Test back/forward/cancel behavior across all steps
• Error scenarios: Simulate IP/DataRaptor failures, verify error handling
• Embedded OmniScripts: Test data passing between parent and child OmniScripts
• Bulk data: Test with large datasets in Loop Blocks and Type Ahead elements

---

Rules / Constraints

Do not generate anti-patterns even if explicitly requested.

---

Scoring: 120 Points Across 6 Categories

Design & Structure (25 points)

Data Integration (20 points)

Error Handling (20 points)

Performance (20 points)

User Experience (20 points)

Security (15 points)

---

CLI Commands

See scripts/cli-reference.sh for the full command reference. Common commands:

# List active OmniScripts
sf data query -q "SELECT Id,Name,Type,SubType,Language,IsActive,VersionNumber FROM OmniProcess WHERE IsActive=true AND OmniProcessType='OmniScript' LIMIT 50" -o <org>

# Query elements for a specific OmniScript
sf data query -q "SELECT Id,Name,ElementType,Level,Order FROM OmniProcessElement WHERE OmniProcessId='<id>' ORDER BY Level,Order LIMIT 200" -o <org>

# Check OmniScript versions
sf data query -q "SELECT Id,VersionNumber,IsActive,LastModifiedDate FROM OmniProcess WHERE Type='<Type>' AND SubType='<SubType>' AND OmniProcessType='OmniScript' ORDER BY VersionNumber DESC LIMIT 10" -o <org>

---

Cross-Skill Integration

---

Gotchas

For common runtime troubleshooting (element not rendering, data not prefilling, IP action failing silently), see references/best-practices.md Section 8.

---

Notes

API: 66.0 | Mode: Strict (warnings block) | Scoring: Block deployment if score < 67

Required upstream skills: building-omnistudio-datamapper, building-omnistudio-integration-procedure

Optional skills: deploying-metadata, building-omnistudio-flexcard, analyzing-omnistudio-dependencies

Creating OmniScripts programmatically: Use REST API (sf api request rest --method POST --body @file.json). Required fields: Name, Type, SubType, Language, VersionNumber. OmniScripts default to IsIntegrationProcedure=false — do NOT set OmniProcessType directly (it is computed). The sf data create record --values flag cannot handle JSON textarea fields like PropertySetConfig. Create child OmniProcessElement records via REST API for each Step and element.

---

Output Expectations

Deliverables produced by this skill:

• OmniScript JSON (assets/omni-process-omniscript.json template) — OmniProcess record ready for REST API creation
• Step element JSON (assets/omni-process-element-step.json template) — OmniProcessElement record for each Step (Level=0)
• Element JSON (assets/omni-process-element-text-block.json and similar) — OmniProcessElement records for child elements (Level=1+)
• Validation report — 120-point score across 6 categories with pass/warn/block threshold result

---

Reference File Index

Credits & Acknowledgments

This skill reflects patterns and conventions established within the Salesforce OmniStudio platform and its practitioner community.

---

<!-- Parent: building-omnistudio-omniscript/SKILL.md -->

OmniScript Best Practices

Applies to: OmniStudio OmniScripts (OmniProcessType='OmniScript')

Companion: See element-types.md for PropertySetConfig reference per element type

---

Table of Contents

1. Step Design Patterns 2. Data Prefill Strategies 3. Validation Patterns 4. Navigation Patterns 5. Performance Optimization 6. Embedding vs Linking OmniScripts 7. Naming Conventions 8. Error Handling 9. Testing Strategies 10. Security Considerations

---

1. Step Design Patterns

Wizard-Style (Multi-Step Sequential)

The default and most common pattern. Each Step represents a phase of the process, with linear forward progression.

When to use:

• Guided intake forms (service requests, applications, enrollments)
• Multi-phase data collection where later steps depend on earlier inputs
• Processes that benefit from chunking to reduce cognitive load

Design rules:

• Limit each Step to 7-10 input elements (cognitive load threshold)
• Group related fields together within a Step
• Place data-fetching actions (DataRaptor Extract, IP Action) at the beginning of the Step they serve
• Use descriptive Step labels that orient the user (e.g., "Contact Information", "Review & Submit")
• The final Step should be a review/confirmation screen

Example structure:

Step 1: "Account Selection"    -> Type Ahead (account search) + DataRaptor Extract (prefill)
Step 2: "Service Details"      -> Select, Text, Date inputs for the request
Step 3: "Attachments"          -> File upload + Text Area for notes
Step 4: "Review & Submit"      -> Text Blocks displaying collected data + Submit Action

Single-Page (All Elements Visible)

All elements rendered on a single Step with no navigation between pages.

When to use:

• Simple forms with 5 or fewer inputs
• Quick-action modals launched from FlexCards
• Inline editing scenarios

Design rules:

• Use a single Step element containing all inputs
• Omit navigation buttons (no Next/Previous needed)
• Keep the total element count low to avoid scroll fatigue
• Consider whether a FlexCard with inline editing would be simpler

Conditional Branching

Steps are shown or hidden based on user input or data conditions.

When to use:

• Processes where the path varies by user selection (e.g., "New" vs "Existing" customer)
• Compliance workflows where certain sections only apply to specific scenarios
• Multi-product intake where product type determines required fields

Design rules:

• Use the show property on Steps with conditional expressions
• Reference data JSON values using merge field syntax: %ShowStep3% or {ShowStep3}
• Set controlling values early in the flow (Step 1 or data prefill)
• Test all permutations of the conditional paths
• Document the branching logic in Step descriptions

{
  "show": {
    "group": {
      "operator": "AND",
      "rules": [
        {
          "field": "CustomerType",
          "condition": "=",
          "data": "New"
        }
      ]
    }
  }
}

Hub-and-Spoke

A central Step allows navigation to sub-sections, each completing independently.

When to use:

• Complex case management with multiple independent sections
• Forms where the user may complete sections in any order
• Processes requiring non-linear data entry

Design rules:

• Central hub Step with Navigate Actions to each spoke
• Each spoke completes and returns to the hub
• Track section completion status in the data JSON
• Display completion indicators on the hub Step

---

2. Data Prefill Strategies

DataRaptor Extract Prefill

Use DataRaptor Extract Actions at the beginning of a Step to populate elements with existing Salesforce data.

Best practice:

• Place the Extract Action as the first element in the Step (lowest Order value)
• Configure executionConditionFormula to skip the fetch if data already exists
• Map Extract output keys to match element names for automatic binding
• Filter the Extract query to return only the needed fields

{
  "bundle": "DR_ExtractAccountDetails",
  "inputMap": {
    "AccountId": "%SelectedAccountId%"
  },
  "outputMap": {
    "AccountName": "AccountName",
    "BillingAddress": "BillingAddress"
  }
}

Integration Procedure Prefill

Use IP Actions for complex prefill that requires server-side logic, aggregation, or external API calls.

Best practice:

• Set remoteOptions.preTransformBundle if data needs shaping before display
• Use executionConditionFormula to avoid re-fetching on back navigation
• Cache results in the data JSON so subsequent Steps can reference them without additional calls

Contextual Prefill (Launch Parameters)

OmniScripts can receive data when launched from FlexCards, Lightning pages, or URLs.

Best practice:

• Document all expected launch parameters in the OmniScript description
• Validate that required parameters are present; show an error Step if missing
• Use Set Values elements to normalize parameter formats before processing

Save & Resume Prefill

When "Save for Later" is enabled, the OmniScript restores the full data JSON on resume.

Best practice:

• Configure saveNameTemplate for meaningful save identifiers
• Set saveExpireInDays to prevent stale saved instances
• Test that all elements re-render correctly from saved JSON
• Handle edge cases where referenced data may have changed between save and resume

---

3. Validation Patterns

Element-Level Validation

Configure validation directly on input elements via PropertySetConfig.

Validation Elements

Use Validation elements for cross-field and business rule validation.

Best practice:

• Place Validation elements at the end of a Step, before the navigation connector
• Write clear, user-actionable error messages
• Reference multiple fields in the validation formula for cross-field checks
• Group related validations in a single Validation element when possible

{
  "validationFormula": "%EndDate% > %StartDate%",
  "errorMessage": "End date must be after the start date."
}

Step-Level Validation

Prevent the user from advancing to the next Step until all validations pass.

Best practice:

• Combine required properties on inputs with Validation elements for complex rules
• Use the Step's validationRequired property to enforce completion
• Display inline validation messages near the field, not only at the top of the page

Server-Side Validation

Use Integration Procedure Actions for validations that require database lookups or external checks.

Best practice:

• Display a loading indicator during server-side validation
• Handle timeout and error responses gracefully
• Cache validation results to avoid redundant server calls on back-navigation

---

4. Navigation Patterns

Standard Linear Navigation

Default back/forward progression through Steps.

Configuration:

• allowSaveForLater: Enable save & resume functionality
• cancelAction: Define behavior when user clicks Cancel (redirect URL or close modal)
• showStepChart: Display step progress indicator
• stepChartPlacement: Position the step chart (top, left, right)

Conditional Step Skipping

Skip Steps that are not relevant based on collected data.

Best practice:

• Use the show property on Steps rather than Navigate Actions for conditional paths
• The OmniScript engine automatically skips hidden Steps during forward navigation
• Test that skipped Steps do not contribute invalid data to the JSON

Custom Navigation Buttons

Override default Next/Previous with Navigate Actions for non-linear flows.

Best practice:

• Maintain a consistent button layout across Steps
• Label navigation buttons with the destination Step name, not generic "Next"
• Disable the Previous button on the first Step
• Consider whether non-linear navigation will confuse the user

Cancel and Exit

Best practice:

• Prompt for confirmation before discarding entered data
• Offer "Save for Later" alongside Cancel when appropriate
• Redirect to a meaningful page after cancellation (not a blank screen)

---

5. Performance Optimization

Lazy Loading Elements

Configure action elements to execute only when their containing Step becomes visible.

Best practice:

• Set executionConditionFormula on DataRaptor Extract and IP Actions
• Use Step-level activation triggers rather than OmniScript-level onLoad actions
• Prefetch only the data needed for the first Step on initial load

Conditional Visibility vs Conditional Rendering

Best practice:

• Use the show property for elements that may not be needed at all
• Avoid rendering large data tables or Loop Blocks that the user may never see

Data Volume in Loop Blocks

Loop Blocks render elements for each item in a data array. Large arrays degrade performance.

Best practice:

• Limit the data array to 50 items or fewer for interactive Loop Blocks
• Implement server-side pagination via Integration Procedures for large datasets
• Use Type Ahead elements instead of Loop Blocks when the user needs to search/select from a large list

Minimize Action Element Count

Each action element (DataRaptor, IP, Remote Action) represents a server round-trip.

Best practice:

• Combine multiple data fetches into a single Integration Procedure where possible
• Fetch all data needed for a Step in one action, not one action per field
• Use Set Values to derive calculated fields client-side instead of calling the server

Image and Static Content

Best practice:

• Host images on a CDN or Salesforce Static Resource rather than embedding base64 in Text Blocks
• Minimize HTML complexity in Text Block elements
• Use the Image element type instead of <img> tags in Text Blocks

---

6. Embedding vs Linking OmniScripts

Embedding (Child OmniScript)

An OmniScript rendered inside another OmniScript as a reusable sub-process.

When to embed:

• The sub-process is a self-contained unit reused across multiple parent OmniScripts
• The parent needs data from the child's interaction (child data merges into parent JSON)
• The user should not leave the parent context

Design rules:

• Pass required data from parent to child via prefillJSON mapping
• Configure the child to suppress its own navigation when embedded
• Test data merge behavior: child data is added to the parent JSON under the child element's name
• Avoid embedding more than 2 levels deep (parent -> child -> grandchild is the practical limit)
• Watch for name collisions between parent and child data JSON keys

Linking (Navigate Action)

A Navigate Action redirects to a separate OmniScript in a new context.

When to link:

• The processes are independent and do not share a data context
• The user is transitioning from one workflow to a different one
• The target OmniScript is also used standalone (not just as a sub-component)

Design rules:

• Pass context data via URL parameters or the Navigate Action's params property
• The linked OmniScript starts fresh with its own data JSON
• Handle the return navigation (redirect back to the originating page if needed)

Decision Matrix

---

7. Naming Conventions

OmniScript Type/SubType

• Type: Business domain or process category. Use PascalCase. Examples: ServiceRequest, MemberEnrollment, ClaimProcessing
• SubType: Specific variation or action. Use PascalCase. Examples: CreateNew, UpdateAddress, FileAppeal
• Language: Use standard locale codes. Default: English

Element Names

• Use PascalCase for all element names
• Prefix action elements with their type: DRExtract_AccountInfo, IP_ValidateEligibility, Nav_ReturnToCase
• Name Steps with the section they represent: Step_ContactInfo, Step_ReviewSubmit
• Name input elements descriptively: FirstName, PreferredContactMethod, RequestedStartDate

Data JSON Keys

• Match element names for automatic binding
• Use consistent casing throughout the OmniScript
• Avoid special characters, spaces, and reserved words in key names
• Document the data JSON schema for complex OmniScripts

---

8. Error Handling

Action Element Errors

Every DataRaptor, Integration Procedure, and Remote Action element should handle failures.

Best practice:

• Set showError: true and provide a meaningful errorMessage in PropertySetConfig
• Use responseJSONPath to extract specific error details from the response
• Implement a fallback Step that displays when critical actions fail
• Log errors server-side via an IP Action for monitoring

User Input Errors

Best practice:

• Show inline error messages immediately on invalid input (not only on Step advance)
• Use red visual indicators and position error text near the offending field
• Provide specific guidance on how to fix the error (not just "Invalid input")

Network and Timeout Errors

Best practice:

• Configure remoteTimeout on IP Actions for long-running operations
• Display a loading indicator during server calls
• Offer a retry option when transient errors occur
• If the OmniScript cannot continue, display a clear message with a support contact

---

9. Testing Strategies

Manual Testing Checklist

• [ ] Walk through all Steps with valid data (happy path)
• [ ] Attempt to advance with missing required fields
• [ ] Enter invalid data for each validated input
• [ ] Exercise all conditional branches (show/hide Steps and elements)
• [ ] Test with prefilled vs empty launch parameters
• [ ] Test Save for Later and Resume
• [ ] Verify data is correctly submitted/saved
• [ ] Test Cancel behavior and confirmation prompt
• [ ] Check rendering on mobile viewport
• [ ] Verify with different user profiles/permission sets

Integration Testing

• [ ] Verify all DataRaptor Extract Actions return expected data
• [ ] Verify all DataRaptor Load Actions create/update records correctly
• [ ] Verify all IP Actions execute and return expected responses
• [ ] Test with integration failures (disable a DataRaptor, verify error handling)
• [ ] Test with large data volumes in Loop Blocks

Cross-Browser and Device Testing

• [ ] Desktop: Chrome, Firefox, Safari, Edge
• [ ] Mobile: iOS Safari, Android Chrome
• [ ] Tablet: verify responsive layout breakpoints
• [ ] Community/Experience Cloud: verify guest and authenticated rendering

---

10. Security Considerations

Data Exposure

• OmniScript data JSON is client-side. Sensitive data (SSNs, passwords, tokens) should be processed server-side in Integration Procedures and never stored in the client JSON.
• Use maskValue on sensitive input elements to prevent shoulder-surfing.
• Strip sensitive fields from the data JSON before the Submit Action using Set Values.

Access Control

• OmniScript visibility is controlled by the page or component it is placed on, not by the OmniScript itself.
• Ensure Integration Procedures enforce record-level and field-level security (FLS).
• Do not rely on hiding Steps or elements as a security mechanism; the data JSON can be inspected client-side.

Input Sanitization

• Validate all user input before passing to DataRaptor Load or IP Actions.
• Use pattern (regex) on text inputs to restrict input format.
• Server-side IPs should validate input independently; do not trust client-side validation alone.

---

11. Common Troubleshooting

---

Key Takeaways

1. Keep Steps focused: 7-10 elements maximum per Step. Split complex processes into more Steps rather than cramming elements. 2. Prefill early, validate often: Load data at the start of each Step and validate before allowing progression. 3. Error handling is not optional: Every server call needs a failure path. Every required input needs validation. 4. Performance is a design constraint: Lazy-load data, limit Loop Block iterations, and minimize server round-trips. 5. Embed sparingly, link freely: Embedding couples OmniScripts tightly. Reserve it for genuine sub-processes. 6. Security is server-side: The client JSON is not a trust boundary. Sensitive logic belongs in Integration Procedures.

<!-- Parent: building-omnistudio-omniscript/SKILL.md -->

OmniScript Element Type Reference

Applies to: OmniStudio OmniScripts (OmniProcessType='OmniScript')

Companion: See best-practices.md for design patterns and usage guidance

Each OmniScript element is stored as an OmniProcessElement child record. The ElementType field identifies the type, and the PropertySetConfig field contains a JSON blob with all configuration.

---

Table of Contents

1. Container Elements 2. Input Elements 3. Display Elements 4. Action Elements 5. Logic Elements 6. Common PropertySetConfig Properties

---

1. Container Elements

Step

Top-level container representing a page/screen in the OmniScript wizard. All other elements are children of a Step.

{
  "label": "Contact Information",
  "chartLabel": "Contact",
  "validationRequired": true,
  "instruction": "Please provide your contact details.",
  "nextLabel": "Continue to Service Details",
  "show": {
    "group": {
      "operator": "AND",
      "rules": [
        { "field": "HasContactInfo", "condition": "=", "data": "false" }
      ]
    }
  }
}

Level: 0 (always top-level) Order: Determines the Step sequence in the wizard

---

Conditional Block

Groups elements that appear or disappear together based on a condition.

{
  "conditionType": "group",
  "show": {
    "group": {
      "operator": "AND",
      "rules": [
        { "field": "CustomerType", "condition": "=", "data": "Business" }
      ]
    }
  }
}

Level: 1+ (child of a Step)

---

Loop Block

Iterates over a data array and renders its child elements for each item.

{
  "loopData": "%OrderLines%",
  "allowAdd": true,
  "allowDelete": true,
  "minItems": 1,
  "maxItems": 20,
  "label": "Order Line Items"
}

Level: 1+ (child of a Step)

---

Edit Block

Provides inline editing of tabular data with row-level add/edit/delete.

{
  "dataSource": "%ContactList%",
  "editFields": ["FirstName", "LastName", "Email", "Phone"],
  "columns": [
    { "label": "First Name", "field": "FirstName", "width": "25%" },
    { "label": "Last Name", "field": "LastName", "width": "25%" },
    { "label": "Email", "field": "Email", "width": "30%" },
    { "label": "Phone", "field": "Phone", "width": "20%" }
  ],
  "allowAdd": true,
  "allowDelete": true
}

Level: 1+ (child of a Step)

---

2. Input Elements

Common Input Properties

All input elements share these base properties:

---

Text

Single-line text input.

{
  "label": "First Name",
  "required": true,
  "placeholder": "Enter your first name",
  "minLength": 2,
  "maxLength": 80,
  "pattern": "^[a-zA-Z\\s'-]+$",
  "patternErrorMessage": "Name may only contain letters, spaces, hyphens, and apostrophes."
}

---

Text Area

Multi-line text input.

{
  "label": "Description",
  "rows": 4,
  "maxLength": 32000,
  "placeholder": "Describe the issue in detail..."
}

---

Number

Numeric input with formatting.

{
  "label": "Quantity",
  "required": true,
  "min": 1,
  "max": 9999,
  "step": 1,
  "format": "0,0",
  "defaultValue": 1
}

---

Currency

Currency input with locale formatting.

{
  "label": "Requested Amount",
  "required": true,
  "currencyCode": "USD",
  "min": 0.01,
  "max": 1000000,
  "precision": 2
}

---

Date

Date picker input.

{
  "label": "Requested Start Date",
  "required": true,
  "dateFormat": "MM/DD/YYYY",
  "minDate": "TODAY",
  "maxDate": "+365"
}

---

Date/Time

Combined date and time picker.

{
  "label": "Appointment Date & Time",
  "dateFormat": "MM/DD/YYYY",
  "timeFormat": "hh:mm A"
}

---

Time

Time-only picker.

{
  "label": "Preferred Time",
  "timeFormat": "hh:mm A",
  "minuteInterval": 15
}

---

Checkbox

Boolean toggle input.

{
  "label": "Terms and Conditions",
  "checkLabel": "I agree to the terms and conditions",
  "required": true,
  "defaultValue": false
}

---

Radio

Radio button group for single selection.

{
  "label": "Contact Preference",
  "required": true,
  "orientation": "vertical",
  "options": [
    { "name": "Email", "value": "Email" },
    { "name": "Phone", "value": "Phone" },
    { "name": "Mail", "value": "Mail" }
  ]
}

---

Select

Dropdown selection input.

{
  "label": "State",
  "required": true,
  "options": [
    { "name": "California", "value": "CA" },
    { "name": "New York", "value": "NY" },
    { "name": "Texas", "value": "TX" }
  ]
}

---

Multi-select

Multiple item selection input.

{
  "label": "Interested Products",
  "options": [
    { "name": "Product A", "value": "ProdA" },
    { "name": "Product B", "value": "ProdB" },
    { "name": "Product C", "value": "ProdC" }
  ],
  "maxSelections": 3
}

---

Type Ahead

Search/autocomplete input that queries a data source as the user types.

{
  "label": "Search Account",
  "dataSource": "DR_SearchAccounts",
  "searchField": "Name",
  "displayField": "Name",
  "valueField": "Id",
  "minCharacters": 3,
  "maxResults": 10,
  "debounce": 300,
  "inputMap": {
    "RecordType": "Customer"
  }
}

---

Email

Email input with built-in format validation.

{
  "label": "Email Address",
  "required": true,
  "placeholder": "name@example.com"
}

---

Telephone

Phone number input with optional masking.

{
  "label": "Phone Number",
  "mask": "(999) 999-9999",
  "placeholder": "(555) 123-4567"
}

---

URL

URL input with built-in format validation.

{
  "label": "Website",
  "placeholder": "https://www.example.com"
}

---

Password

Masked text input for sensitive values.

{
  "label": "Temporary PIN",
  "required": true,
  "minLength": 6,
  "maxLength": 6,
  "pattern": "^\\d{6}$",
  "patternErrorMessage": "PIN must be exactly 6 digits."
}

---

Range

Slider input for selecting a value within a range.

{
  "label": "Satisfaction Rating",
  "min": 1,
  "max": 10,
  "step": 1,
  "showValue": true,
  "defaultValue": 5
}

---

Signature

Signature capture pad for e-signatures.

{
  "label": "Customer Signature",
  "required": true,
  "penColor": "#000000",
  "backgroundColor": "#FFFFFF",
  "width": 400,
  "height": 150,
  "clearLabel": "Clear Signature"
}

---

File

File upload input.

{
  "label": "Supporting Documents",
  "maxFileSize": 5242880,
  "allowedExtensions": "pdf,jpg,png,docx",
  "maxFiles": 5,
  "uploadLabel": "Upload Document"
}

---

3. Display Elements

Text Block

Static content display. Supports HTML and merge fields.

{
  "textContent": "<p>Welcome, <strong>%FirstName%</strong>. Please review the following information.</p>",
  "sanitize": true
}

---

Headline

Section heading element.

{
  "text": "Account Details",
  "level": 2
}

---

Aggregate

Calculated summary display based on data in the OmniScript JSON.

{
  "label": "Total Amount",
  "aggregateExpression": "SUM(%OrderLines:Amount%)",
  "format": "$0,0.00",
  "dataType": "currency"
}

---

Disclosure

Expandable/collapsible content section.

{
  "label": "Additional Information",
  "defaultExpanded": false
}

---

Image

Image display element.

{
  "imageURL": "/resource/CompanyLogo",
  "altText": "Company Logo",
  "width": "200px"
}

---

Chart

Data visualization element.

{
  "chartType": "pie",
  "dataSource": "%CoverageBreakdown%",
  "labelField": "CoverageType",
  "valueField": "Amount",
  "title": "Coverage Distribution"
}

---

4. Action Elements

DataRaptor Extract Action

Executes a DataRaptor Extract to pull data from Salesforce.

{
  "bundle": "DR_ExtractAccountDetails",
  "inputMap": {
    "AccountId": "%SelectedAccountId%"
  },
  "outputMap": {
    "AccountName": "AccountName",
    "BillingStreet": "BillingStreet",
    "BillingCity": "BillingCity",
    "BillingState": "BillingState",
    "BillingPostalCode": "BillingPostalCode"
  },
  "executionConditionFormula": "IF(%SelectedAccountId% != '', true, false)",
  "showError": true,
  "errorMessage": "Unable to retrieve account details. Please try again."
}

---

DataRaptor Load Action

Executes a DataRaptor Load to write data to Salesforce.

{
  "bundle": "DR_CreateServiceRequest",
  "inputMap": {
    "AccountId": "%SelectedAccountId%",
    "Subject": "%RequestSubject%",
    "Description": "%RequestDescription%",
    "Priority": "%RequestPriority%"
  },
  "showError": true,
  "errorMessage": "Failed to create the service request. Please contact support."
}

---

Integration Procedure Action

Calls a server-side Integration Procedure.

{
  "ipMethod": "Eligibility_CheckMember",
  "inputMap": {
    "MemberId": "%MemberId%",
    "ServiceDate": "%RequestedDate%"
  },
  "outputMap": {
    "IsEligible": "EligibilityResult",
    "PlanName": "MemberPlan",
    "CopayAmount": "EstimatedCopay"
  },
  "remoteOptions": {
    "preTransformBundle": "DR_TransformEligibilityInput",
    "postTransformBundle": "DR_TransformEligibilityOutput"
  },
  "remoteTimeout": 30000,
  "showError": true,
  "errorMessage": "Eligibility check failed. Please verify member ID and try again."
}

---

Remote Action

Calls an Apex @RemoteAction method or REST endpoint.

{
  "remoteClass": "CustomEligibilityService",
  "remoteMethod": "checkEligibility",
  "inputMap": {
    "memberId": "%MemberId%"
  },
  "outputMap": {
    "result": "EligibilityResult"
  },
  "showError": true
}

---

Navigate Action

Navigates to another page, OmniScript, or URL.

{
  "targetType": "OmniScript",
  "targetId": "ServiceRequest_FollowUp_English",
  "params": {
    "CaseId": "%CreatedCaseId%",
    "AccountId": "%SelectedAccountId%"
  }
}

---

Email Action

Sends an email using a Salesforce email template.

{
  "emailTemplateId": "ServiceRequestConfirmation",
  "recipientMap": {
    "toAddress": "%ContactEmail%",
    "whatId": "%CreatedCaseId%"
  }
}

---

DocuSign Envelope Action

Triggers a DocuSign envelope for e-signature.

{
  "templateId": "abc123-template-id",
  "recipientMap": {
    "signer1": {
      "name": "%CustomerName%",
      "email": "%CustomerEmail%"
    }
  }
}

---

5. Logic Elements

Set Values

Assigns values to data JSON keys. Used for data transformation, defaults, and computed values.

{
  "elementValueMap": {
    "FullName": "CONCAT(%FirstName%, ' ', %LastName%)",
    "SubmissionDate": "TODAY()",
    "Status": "Submitted",
    "RequestId": "CONCAT('SR-', %CaseNumber%)"
  }
}

---

Validation

Validates data using a formula expression. Blocks Step advancement when validation fails.

{
  "validationFormula": "%EndDate% > %StartDate%",
  "errorMessage": "End date must be after the start date."
}

Multiple conditions example:

{
  "validationFormula": "AND(%Age% >= 18, %Age% <= 120)",
  "errorMessage": "Age must be between 18 and 120."
}

---

Formula

Calculates a value using a formula expression and stores the result in the data JSON.

{
  "label": "TotalWithTax",
  "expression": "%SubTotal% * (1 + %TaxRate% / 100)",
  "dataType": "number",
  "decimalPlaces": 2
}

---

Submit Action

Final submission action that processes collected data. Typically the last element in the last Step.

{
  "postMessage": "Your service request has been submitted successfully.",
  "preTransformBundle": "DR_PrepareSubmission",
  "postTransformBundle": "DR_ProcessResponse",
  "submitLabel": "Submit Request",
  "validationRequired": true,
  "redirectTemplateUrl": "/case/%CreatedCaseId%"
}

---

6. Common PropertySetConfig Properties

These properties apply across multiple element types.

Conditional Visibility (show)

Controls whether an element is rendered.

{
  "show": {
    "group": {
      "operator": "AND",
      "rules": [
        { "field": "CustomerType", "condition": "=", "data": "Business" },
        { "field": "AnnualRevenue", "condition": ">", "data": "1000000" }
      ]
    }
  }
}

Operators: AND, OR Conditions: =, !=, >, <, >=, <=, contains, starts with, ends with, is null, is not null

Nested Groups

{
  "show": {
    "group": {
      "operator": "OR",
      "rules": [
        { "field": "Status", "condition": "=", "data": "Active" },
        {
          "group": {
            "operator": "AND",
            "rules": [
              { "field": "Status", "condition": "=", "data": "Pending" },
              { "field": "HasApproval", "condition": "=", "data": "true" }
            ]
          }
        }
      ]
    }
  }
}

Merge Fields

Reference data JSON values in element configuration using %FieldName% syntax.

Layout Properties

Data Binding

---

Quick Reference: Element Type to OmniProcessElement.ElementType