Introduction
OmniScript naming conventions are a set of standards used to make Vlocity/OmniStudio scripts, elements, and integrations easy to find, maintain, and govern. Consistent names improve team collaboration, simplify troubleshooting, and make CI/CD and environment promotion predictable.
Why naming matters
OmniScripts produce JSON definitions that are referenced by other assets (DataRaptors, Integration Procedures, Remote Actions, SubOmniScripts, etc.). A clear naming scheme prevents collisions, clarifies ownership, and provides immediate context about purpose, scope, and version.
General rules (best practices)
Apply the following rules across OmniScripts and related assets:
– Use a short project prefix to group assets (e.g., CS for CodeSierra or ACME for a client).
– Use a functional module or domain token (e.g., Billing, Policy, Customer).
– Use the object or action being performed (e.g., CreateAccount, UpdatePolicy).
– Add a version suffix for non-destructive updates (e.g., _v1, _v2).
– Use camelCase for variable and element names (API names) and PascalCase or kebab-case for script-level identifiers if your team prefers human-readable words.
– Avoid spaces and special characters. Start names with a letter. Keep names concise (preferably under 50 characters).
Recommended pattern (high level)
Adopt a predictable pattern for OmniScripts and related assets. Example templates:
PROJECT_Module_Object_Action_v1
Or if you prefer fewer segments:
PROJECT_Module_Action_v1
Element & API name conventions
OmniScript elements (Text Block, Input, Step, Integration Action) have two important properties: Label and Name (API name). Label is user-facing; Name is used in the JSON and by other components. Rules:
– Label: human-friendly, can contain spaces and punctuation (used in the UI).
– Name: no spaces, no special characters except underscore; use camelCase for field-like items: customerFirstName, policyEffectiveDate.
– For structural items like steps or sub-omni scripts use PascalCase with prefix: CS_Billing_StepCollectAddress.
Integration & DataRaptor naming
Keep integration artifacts aligned with OmniScript names so relationships are obvious:
CS_Billing_IP_CreateAccount_v1
(Integration Procedure)
CS_Billing_DR_ExtractAccount
(DataRaptor Extract)
Key points:
– Prefix with the same project token (CS) and module (Billing).
– Use a short type token to indicate the asset (e.g., IP for Integration Procedure, DR for DataRaptor, RA for Remote Action).
SubOmniScript and Reusable Components
SubOmniScripts and other reusable blocks should reflect their usage and be generic enough to be shared across flows:
CS_Common_SubAddressCapture_v1
Don’t include consumer-specific text in a reusable name; keep it domain-generic.
Versioning & environment suffixes
Keep version numbers in the name (as a suffix) when you need side-by-side versions. For environment-specific temporary artifacts, prefer metadata or deployment-driven tagging rather than embedding environment in the name. If you must, use a short suffix:
_v1, _v2, _uat, _prod
Examples
Practical examples using the pattern PROJECT_Module_Type_Action_vX:
CS_Customer_OS_CreateAccount_v1
OmniScript to create an account
CS_Customer_DR_AccountExtract
DataRaptor for extracting account fields
CS_Customer_IP_CreateAccountIP_v1
Integration Procedure called by the OmniScript
CS_Common_SubAddressCapture_v1
Reusable SubOmniScript
Governance & automation
Document the naming standard in your team wiki and enforce it during code reviews. Use pre-deployment validation scripts to detect naming violations. Adopt an automated linter or a simple checklist in CI/CD to verify prefixes, versioning, and length.
Summary – quick checklist
– Start with a project prefix (e.g., CS).
– Add a module/domain token (e.g., Billing).
– Add an asset-type token (e.g., OS, IP, DR).
– Use a clear action or object name (e.g., CreateAccount).
– Append version (_v1) if needed.
Consistent OmniScript naming saves time, reduces errors, and scales with your team — especially when you’re managing many assets across environments.