PluginBench
Skill
Pass
Audit score 90

omnistudio-omniscript-generate

forcedotcom/sf-skills

Build guided multi-step OmniScripts with 120-point validation scoring for Salesforce OmniStudio.

What is omnistudio-omniscript-generate?

OmniStudio OmniScript creation and validation skill for building declarative, step-based guided digital experiences. Use when designing multi-step interactive processes that collect user input, orchestrate Integration Procedures and DataRaptors, and present results—all without code. Includes 120-point scoring with PASS (90+), REVIEW (67-89), and BLOCK (<67) thresholds.

  • Generate well-structured OmniScripts from requirements with appropriate element types for each step
  • Configure PropertySetConfig JSON for elements with data binding, validation, and conditional logic
  • Map dependencies to Integration Procedures, DataRaptors, and embedded OmniScripts before deployment
  • Trace data flow through OmniScript JSON structure from prefill through user input to final save actions
  • Validate OmniScripts against 120-point scoring criteria across 6 categories
  • Design container elements (Steps, Conditional Blocks, Loop Blocks, Edit Blocks) and input elements (Text, Date, Select, File, Signature, etc.)

How to install omnistudio-omniscript-generate

npx skills add https://github.com/forcedotcom/sf-skills --skill omnistudio-omniscript-generate
Prerequisites
  • Salesforce CLI (sf) version 2.0.0 or higher
  • Access to a Salesforce org with OmniStudio enabled
  • Existing Integration Procedures and DataRaptors if the OmniScript will orchestrate backend logic
  • Understanding of OmniScript Type/SubType/Language composite key structure
Claude Code
Cursor
Windsurf
Cline

How to use omnistudio-omniscript-generate

  1. 1.Gather required inputs: Type (process category), SubType (variation), Language, Purpose, target org, and data sources
  2. 2.Check existing OmniScripts to avoid duplication and identify reusable Integration Procedures or DataRaptors
  3. 3.Design each step and select appropriate element types (container elements like Steps and Conditional Blocks, input elements like Text, Date, Select, File, Signature)
  4. 4.Configure PropertySetConfig JSON for each element with data binding, validation rules, and conditional visibility logic
  5. 5.Map all dependencies to Integration Procedures, DataRaptors, and embedded OmniScripts using omnistudio-dependencies-analyze
  6. 6.Validate the OmniScript against the 120-point scoring criteria to reach PASS (90+) threshold
  7. 7.Deploy the OmniScript metadata to the target org and activate it via the IsActive field

Use cases

Good for
  • Building a multi-step ServiceRequest creation OmniScript that collects user input, validates data, and triggers backend Integration Procedures
  • Designing an Enrollment workflow with conditional steps based on user selections and data-driven dropdown options
  • Creating a ClaimSubmission process that loops over line items, captures signatures, and uploads supporting documents
  • Updating an existing OmniScript configuration to add new validation rules or modify element PropertySetConfig
  • Validating an OmniScript design against best practices and deployment readiness before activation
Who it's for
  • Salesforce OmniStudio developers building guided digital experiences
  • Business analysts designing multi-step customer processes
  • Administrators deploying OmniScripts to production orgs
  • Developers integrating OmniScripts with Integration Procedures and DataRaptors

omnistudio-omniscript-generate FAQ

When should I use OmniScript vs. Screen Flow?

OmniScripts are best for complex, multi-step guided processes with orchestration of backend logic. For simple single-screen data entry, use Screen Flows. For data display without interaction, use FlexCards.

What is the Type/SubType/Language triplet?

These three values uniquely identify an OmniScript and form the composite key. Example: Type=ServiceRequest, SubType=NewCase, Language=English. All three are required and only one version per triplet can be active.

What is PropertySetConfig?

PropertySetConfig is a JSON blob containing all element configuration—layout, data binding, validation rules, and conditional visibility. This is where the real logic lives for each element.

What is the correct build order for OmniStudio components?

Follow this order: omnistudio-dependencies-analyze → omnistudio-datamapper-generate → omnistudio-integration-procedure-generate → omnistudio-omniscript-generate → omnistudio-flexcard-generate. OmniScripts consume Integration Procedures and DataRaptors, so build those first.

What do the 120-point scoring thresholds mean?

PASS (90+): Deploy the OmniScript. REVIEW (67-89): Review before deployment. BLOCK (<67): Fix required before deployment. Scoring evaluates OmniScript quality across 6 categories.

Full instructions (SKILL.md)

Source of truth, from forcedotcom/sf-skills.


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:

InputDescriptionDefault
TypeProcess category (e.g., ServiceRequest, Enrollment)None — required
SubTypeSpecific variation (e.g., NewCase, UpdateAddress)None — required
LanguageLocale for the OmniScriptEnglish
PurposeBusiness process this OmniScript guidesNone — required
Target orgOrg alias for deploymentCurrent default org
Data sourcesObjects/APIs to query or updateIdentify 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

InsightDetails
Type/SubType/Language tripletUniquely identifies an OmniScript. All three values are required and form the composite key. Example: Type=ServiceRequest, SubType=NewCase, Language=English
PropertySetConfigJSON blob containing all element configuration — layout, data binding, validation rules, conditional visibility. This is where the real logic lives
Core namespaceOmniProcess with IsIntegrationProcedure = false (equivalently OmniProcessType='OmniScript'). Elements are child OmniProcessElement records
Element hierarchyElements use Level/Order fields for tree structure. Level 0 = Steps, Level 1+ = elements within steps. Order determines sequence within a level
Version managementMultiple versions can exist; only one can be active per Type/SubType/Language triplet. Activate via the IsActive field
Data JSONOmniScripts 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 TypePurposeKey Config
StepTop-level container for a group of UI elements; each Step is a page in the wizardchartLabel, knowledgeOptions, show (conditional visibility)
Conditional BlockShow/hide a group of elements based on conditionsconditionType, show expression
Loop BlockIterate over a data list and render elements for each itemloopData (JSON path to array)
Edit BlockInline editing container for tabular dataeditFields, dataSource

Input Elements

Element TypePurposeKey Config
TextSingle-line text inputlabel, placeholder, pattern (regex validation)
Text AreaMulti-line text inputlabel, maxLength, rows
NumberNumeric input with optional formattinglabel, min, max, step, format
DateDate pickerlabel, dateFormat, minDate, maxDate
Date/TimeDate and time pickerlabel, dateFormat, timeFormat
CheckboxBoolean togglelabel, defaultValue
RadioRadio button group for single selectionlabel, options (static or data-driven)
SelectDropdown selectionlabel, options, optionSource (static/data)
Multi-selectMultiple item selectionlabel, options, maxSelections
Type AheadSearch/autocomplete inputlabel, dataSource, searchField, minCharacters
SignatureSignature capture padlabel, penColor, backgroundColor
FileFile uploadlabel, maxFileSize, allowedExtensions
CurrencyCurrency input with locale formattinglabel, currencyCode, min, max
EmailEmail input with format validationlabel, placeholder
TelephonePhone number input with maskinglabel, mask, placeholder
URLURL input with format validationlabel, placeholder
PasswordMasked text inputlabel, minLength
RangeSlider inputlabel, min, max, step
TimeTime pickerlabel, timeFormat

Display Elements

Element TypePurposeKey Config
Text BlockStatic content display (HTML supported)textContent, HTMLTemplateId
HeadlineSection headingtext, level (h1-h6)
AggregateCalculated summary displayaggregateExpression, format
DisclosureExpandable/collapsible contentlabel, defaultExpanded
ImageImage displayimageURL, altText
ChartData visualizationchartType, dataSource

Action Elements

Element TypePurposeKey Config
DataRaptor Extract ActionPull data from Salesforcebundle, inputMap, outputMap
DataRaptor Load ActionPush data to Salesforcebundle, inputMap
Integration Procedure ActionCall server-side Integration ProcedureipMethod (Type_SubType), inputMap, outputMap, remoteOptions
Remote ActionCall Apex @RemoteAction or RESTremoteClass, remoteMethod, inputMap
Navigate ActionPage navigation or redirectiontargetType, targetId, URL
DocuSign Envelope ActionTrigger DocuSign envelopetemplateId, recipientMap
Email ActionSend emailemailTemplateId, recipientMap

Logic Elements

Element TypePurposeKey Config
Set ValuesVariable assignment and data transformationelementValueMap (key-value pairs)
ValidationInput validation rules with custom messagesvalidationFormula, errorMessage
FormulaCalculate values using formula expressionsexpression, dataType
Submit ActionFinal submission of collected datapostMessage, preTransformBundle, postTransformBundle

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

Anti-PatternImpactCorrect Pattern
Circular OmniScript embeddingInfinite rendering loopMap dependency tree; never embed A in B if B embeds A
Unbounded DataRaptor ExtractPerformance degradationAdd filter conditions; limit returned records
Missing input validationBad data entryAdd Validation elements or pattern/required on inputs
Hardcoded Salesforce IDsDeployment failure across orgsUse merge fields or Custom Settings/Metadata
Integration Procedure (IP) Action without error handlingSilent failuresConfigure showError, errorMessage in PropertySetConfig
Large images in Text BlocksSlow page loadUse Image elements with optimized URLs
Too many elements per StepPoor user experienceLimit to 7-10 input elements per Step
Missing conditional visibilityIrrelevant fields shownUse show expressions to hide inapplicable elements

Do not generate anti-patterns even if explicitly requested.


Scoring: 120 Points Across 6 Categories

Design & Structure (25 points)

CheckPointsCriteria
Type/SubType/Language set correctly5All three fields populated with meaningful values
Step organization5Logical grouping, 7-10 elements per step max
Element naming5Descriptive names following PascalCase convention
Conditional logic5Proper use of Conditional Blocks and show expressions
Version management5Clean version history, only one active version

Data Integration (20 points)

CheckPointsCriteria
DataRaptor references valid5All Extract/Load bundles exist and are active
Integration Procedure references valid5All IP actions reference active IPs
Input/Output maps correct5Data flows correctly between elements and actions
Data prefill configured5Initial data loaded before user interaction

Error Handling (20 points)

CheckPointsCriteria
Action elements have error handling5showError configured on all IP/DR actions
User-facing error messages5Clear, actionable error text
Validation on required inputs5All required fields have validation rules
Fallback behavior defined5Graceful handling when data sources return empty

Performance (20 points)

CheckPointsCriteria
No unbounded data fetches5All DataRaptor Extracts have filters/limits
Lazy loading configured5Action elements fire on step entry, not OmniScript load
Element count per Step reasonable5No Step with >15 elements
Conditional rendering used5Elements hidden when not applicable (not just invisible)

User Experience (20 points)

CheckPointsCriteria
Logical step flow5Steps follow natural task progression
Input labels and help text5All inputs have clear labels and contextual help
Navigation controls5Back, Next, Cancel, Save for Later configured appropriately
Responsive layout5Elements configured for mobile and desktop breakpoints

Security (15 points)

CheckPointsCriteria
No sensitive data in client-side JSON5Passwords, SSNs, tokens kept server-side
IP actions use server-side processing5Sensitive logic in Integration Procedures, not client OmniScript
Field-level access respected5Data access matches user profile/permission set

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

From SkillTo omnistudio-omniscript-generateWhen
omnistudio-dependencies-analyze-> omnistudio-omniscript-generate"Analyze dependencies before building OmniScript"
omnistudio-datamapper-generate-> omnistudio-omniscript-generate"DataRaptor ready, build the OmniScript that uses it"
omnistudio-integration-procedure-generate-> omnistudio-omniscript-generate"IP ready, wire it into the OmniScript action"
From omnistudio-omniscript-generateTo SkillWhen
omnistudio-omniscript-generate-> omnistudio-flexcard-generate"Build FlexCard that launches this OmniScript"
omnistudio-omniscript-generate-> platform-metadata-deploy"Deploy OmniScript to target org"
omnistudio-omniscript-generate-> omnistudio-dependencies-analyze"Map full dependency tree before deployment"
omnistudio-omniscript-generate-> omnistudio-integration-procedure-generate"Need a new IP for this OmniScript action"
omnistudio-omniscript-generate-> omnistudio-datamapper-generate"Need a DataRaptor for data prefill"

Gotchas

IssueResolution
Multi-language OmniScriptCreate separate versions per Language with shared Type/SubType; use translation workbench for labels
Embedded OmniScript data passingMap parent data JSON keys to child OmniScript input via prefillJSON; test data round-trip
Large Loop Block datasetsPaginate or limit DataRaptor results; consider server-side filtering in Integration Procedure (IP)
OmniScript in FlexCard flyoutEnsure FlexCard passes required context data; test flyout sizing
Community/Experience Cloud deploymentVerify OmniScript component is available in Experience Builder; check guest user permissions
Save & Resume (Save for Later)Configure saveNameTemplate, saveExpireInDays; test resume with partial data
Versioning conflictsDeactivate old version before activating new; never have two active versions for same Type/SubType/Language triplet
Custom LWC in OmniScriptRegister LWC as OmniScript-compatible; follow omniscript-lwc namespace conventions
Namespaced orgsIf deploying into a managed OmniStudio package org, prefix bundle names and API names with the appropriate namespace (e.g., omnistudio__)
OmniProcessType cannot be set on createOmniProcessType is computed from IsIntegrationProcedure (false for OmniScripts); do not set it directly

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: omnistudio-datamapper-generate, omnistudio-integration-procedure-generate

Optional skills: platform-metadata-deploy, omnistudio-flexcard-generate, omnistudio-dependencies-analyze

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

FileWhen to read
references/element-types.mdPhase 2 — Element selection: read before configuring PropertySetConfig for any element type
references/best-practices.mdPhase 2-5 — Design patterns: read for step design, data prefill, validation, navigation, performance, and troubleshooting guidance
assets/omni-process-omniscript.jsonPhase 3 — Generation: use as the OmniProcess record template when building the OmniScript via REST API
assets/omni-process-element-step.jsonPhase 3 — Generation: use as the Step (Level=0) OmniProcessElement record template
assets/omni-process-element-text-block.jsonPhase 3 — Generation: use as the Text Block element template; adapt for other display element types
scripts/check-duplicate-omniscript.shPhase 3 — Run before creating a new OmniScript to verify no duplicate Type/SubType/Language exists
scripts/deploy-omniscript.shPhase 4 — Run to deploy OmniScript and verify activation; includes prerequisite checks and error recovery
scripts/cli-reference.shAny phase — Full CLI command reference for querying, retrieving, deploying, and verifying OmniScripts