Explain OmniScript Naming Conventions

Posted by Vinay Vernekar 19th January 2026

Overview

OmniScript naming conventions are a set of disciplined rules and patterns used when naming OmniScripts and their related components in OmniStudio (formerly Vlocity). Consistent naming improves maintainability, discoverability, and collaboration across teams implementing solution flows in Salesforce Industries. This guide outlines recommended patterns, examples, and best practices for OmniScript names, steps, elements, and related artifacts.

Why naming conventions matter

Clear, consistent names help with:

  • Faster navigation and search in large orgs
  • Safer deployments and package management
  • Predictable integration between OmniScripts, DataRaptors, Integration Procedures, and Apex
  • Simplified troubleshooting and handoffs between teams

General rules

Use these rules as the foundation of your naming convention:

  • Use a short project or company prefix (e.g., CS for CodeSierra) to avoid collisions across managed packages or multiple teams.
  • Include object or domain/context (e.g., Sales, Billing, Claims).
  • Use a type identifier for the artifact (OS for OmniScript, DR for DataRaptor, IP for Integration Procedure).
  • Use PascalCase or snake_case consistently for readability (choose one and apply across the org).
  • Avoid spaces and special characters; use underscores (_) or no separator depending on team standard.
  • Include a semantic version when applicable (v1, v2 or v1_0).
  • Keep the developer name short but descriptive; keep labels friendly for end users where needed.

Recommended naming patterns

Below are recommended patterns for different artifact types. Replace placeholders as needed.

<Prefix>_OS_<Domain>_<>FlowName>_v<MajorMinor>

Examples:

CS_OS_Sales_NewCustomer_v1
CS_OS_Billing_UpdatePaymentMethod_v1_1

OmniScript elements and internal components

Give meaningful names to blocks, steps, actions and variables. Use consistent element prefixes to make intent clear.

  • Script Steps / Blocks: Step_ContactInfo, Block_Payment
  • Actions: Action_InvokeIP_GetRates, Action_ShowError
  • SetValues / Variables: var_CustomerId, var_TotalPrice
  • Mapping/JSON: map_PricesResponse

Related artifacts naming

Ensure OmniScript-related components follow similar patterns so they’re easy to locate and associate.

  • DataRaptor Extract/Load: <Prefix>_DR_<Domain>_<Purpose>_v<1> — example: CS_DR_Sales_GetAccount_v1
  • Integration Procedures: <Prefix>_IP_<Domain>_<Action>_v<1> — example: CS_IP_Billing_CalculateTax_v1
  • DataRaptor Transform/Transform-JSON: include TR or DRTR as needed.
  • Apex classes used by OmniScript: CS_OSHelper_AccountMerge or CS_OS_Integration_GetRates

Versioning strategy

Use semantic versioning for major changes that break backward compatibility. For small fixes, increment patch version. When making non-breaking UI/label changes, avoid creating new versions unless the data model changes or the flow logic changes substantially.

Example:

CS_OS_Sales_NewCustomer_v1 (initial release)
CS_OS_Sales_NewCustomer_v2 (major redesign with new data model)
CS_OS_Sales_NewCustomer_v2_1 (minor enhancements)

Best practices and governance

  • Document your naming convention in a central wiki and include examples.
  • Enforce via checklist during PR/solution reviews.
  • Create a prefix registry for teams/projects to avoid duplicate prefixes.
  • Keep user-facing labels friendly; developer names should be structured and machine-friendly.
  • Use tags or custom metadata to add searchable metadata when possible.

Sample quick reference

Patterns:

CS_OS___v
CS_DR___v
CS_IP___v

Conclusion

Consistent OmniScript naming conventions reduce ambiguity, accelerate development, and make long-term maintenance manageable. Adapt the patterns above to your organization’s needs, document them, and enforce them through reviews and automation where possible.