/omnistudio-omniscript-generate

name: omnistudio-omniscript-generate
description: "OmniStudio OmniScript creation and validation with 120-point scoring. Use when building guided digital experiences, multi-step forms, or interactive processes that orchestrate Integration Procedures and Data Mappers. TRIGGER when: user creates OmniScripts, designs step flows, configures element types, or reviews existing OmniScript configurations. DO NOT TRIGGER when: building FlexCards (use omnistudio-flexcard-generate), creating Integration Procedures directly (use omnistudio-integration-procedure-generate), or analyzing dependencies (use omnistudio-dependencies-analyze)."
metadata:
  cliTools:
    - tool: ["sf"]
      semver: ">=2.0.0"
  relatedSkills:
    - "omnistudio-datamapper-generate"
    - "omnistudio-dependencies-analyze"
    - "omnistudio-flexcard-generate"
    - "omnistudio-integration-procedure-generate"
    - "platform-metadata-deploy"
  version: "1.0"
  domains: ["OmniStudio"]

omnistudio-omniscript-generate: 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**: [PASS] 90+ (Deploy) | [REVIEW] 67-89 (Review) | [BLOCK] <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 `omnistudio-flexcard-generate`), creating Integration Procedures directly (use `omnistudio-integration-procedure-generate`), mapping full dependency trees (use `omnistudio-dependencies-analyze`), deploying metadata to org (use `platform-metadata-deploy`)

---

Required Inputs

Gather these before building:

| Input | Description | Default | |-------|-------------|---------| | **Type** | Process category (e.g., `ServiceRequest`, `Enrollment`) | None — required | | **SubType** | Specific variation (e.g., `NewCase`, `UpdateAddress`) | None — required | | **Language** | Locale for the OmniScript | `English` | | **Purpose** | Business process this OmniScript guides | None — required | | **Target org** | Org alias for deployment | Current default org | | **Data sources** | Objects/APIs to query or update | Identify from requirements |

---

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

**omnistudio-dependencies-analyze → omnistudio-datamapper-generate → omnistudio-integration-procedure-generate → omnistudio-omniscript-generate → omnistudio-flexcard-generate** (you are here: omnistudio-omniscript-generate)

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

---

Key Insights

| Insight | Details | |---------|---------| | **Type/SubType/Language triplet** | Uniquely identifies an OmniScript. All three values are required and form the composite key. Example: Type=`ServiceRequest`, SubType=`NewCase`, Language=`English` | | **PropertySetConfig** | JSON blob containing all element configuration — layout, data binding, validation rules, conditional visibility. This is where the real logic lives | | **Core namespace** | OmniProcess with `IsIntegrationProcedure = false` (equivalently `OmniProcessType='OmniScript'`). Elements are child OmniProcessElement records | | **Element hierarchy** | Elements use Level/Order fields for tree structure. Level 0 = Steps, Level 1+ = elements within steps. Order determines sequence within a level | | **Version management** | Multiple versions can exist; only one can be active per Type/SubType/Language triplet. Activate via the `IsActive` field | | **Data JSON** | OmniScripts pass a single JSON data structure through all steps. Elements read from and write to this shared JSON via merge field syntax |

---

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

| Element Type | Purpose | Key Config | |-------------|---------|------------| | **Step** | Top-level co