Explain OmniScript Naming Conventions

Posted by Vinay Vernekar 21st January 2026

Introduction

OmniScript naming conventions provide a standardized way to name OmniScripts, elements, and steps in Salesforce Industries (Vlocity). Consistent naming improves maintainability, readability, and makes deployment and troubleshooting much easier — especially in large implementations with multiple developers.

Why Naming Conventions Matter

Using clear, consistent names helps teams quickly identify purpose, context, and ownership of OmniScripts. Good names reduce onboarding time, prevent duplicate functionality, and make automated deployments and merge conflict resolution simpler.

Core Principles

Keep these principles in mind when naming OmniScripts and their elements:

  • Be descriptive but concise
  • Use a predictable structure (prefixes/suffixes)
  • Include context such as object, action, and module
  • Use separators (underscore or hyphen) consistently
  • Avoid special characters and spaces

Naming Structure (Recommended Pattern)

A commonly used pattern combines five parts: OrgPrefix_Module_Object_Action_Version. All parts are optional except those needed for clarity. Use underscores (_) to separate parts.

Pattern breakdown:

  • OrgPrefix — short prefix for the team or org (e.g., CS for CodeSierra)
  • Module — functional area or product (e.g., Billing, Orders)
  • Object — primary sObject or domain concept (e.g., Account, Policy)
  • Action — what the OmniScript does (e.g., Create, Update, Quote)
  • Version — optional short version tag (e.g., v1, v2), or date code like 202501

Example OmniScript names:

CS_Billing_Invoice_Create_v1

CS_Orders_Order_Quote_v2

Naming for Internal Elements (Steps, DataRaptors, Integration Procedures)

Apply similar conventions to elements inside OmniScripts. Include element type and intent so reviewers can understand without opening the configuration.

Suggested element naming patterns:

  • Step: Step_#_ShortDescription → Step_10_CustomerSearch
  • Action: Action_ShortDescription → Action_GetRates
  • DataRaptor: DR_Object_Intent → DR_Account_GetByExternalId
  • Integration Procedure: IP_Module_Intent → IP_Billing_CalculateTax

Naming Input/Output Variables and JSON Paths

For variables, use camelCase or snake_case consistently and include scope if needed (e.g., input_, output_).

input_customerId or customerIdInput

Versioning and Lifecycle

Use a clear version strategy. Options include:

  • Semantic short version: v1, v2
  • Date-based: 202601 (YYYYMM) to indicate build month
  • Suffix for experimental features: _exp or _beta

When creating a major redesign, increment the version in the name rather than overwriting the existing OmniScript. This preserves historical behavior and simplifies rollback.

Best Practices

  • Document the naming standard in your team’s README or architecture guide.
  • Limit length — keep names under 80 characters when possible.
  • Prefer meaningful words over cryptic abbreviations; create an abbreviation glossary if abbreviations are required.
  • Use consistent case (PascalCase for OmniScripts, snake_case for variables, for example).
  • Include owner or team prefix for large organizations (CS, FIN, OPS).
  • Review names during pull requests and code reviews.

Common Mistakes to Avoid

  • No standard prefix — makes scripts hard to locate
  • Overly verbose names — cumbersome and error-prone
  • Inconsistent separators (mixing hyphens and underscores)
  • Embedding environment-specific data (e.g., DEV, QA) in the main name — use metadata or tags instead

Examples (Realistic)

OmniScripts:

CS_Billing_Payment_Create_v1

CS_Policy_Purchase_Quote_v3

Internal elements:

Step_10_LookupCustomer

DR_Policy_GetByNumber

IP_Billing_CalcDiscount

Conclusion

Adopting clear OmniScript naming conventions pays dividends in maintainability, team collaboration, and faster troubleshooting. Define a simple pattern that fits your organization, document it, and enforce it through reviews and CI checks when possible.