Explain OmniScript Naming Conventions

Posted by Vinay Vernekar 6th January 2026

Why consistent OmniScript naming matters

OmniScript naming conventions improve discoverability, maintenance, and reuse of Salesforce Industries (Vlocity) OmniScripts, Actions, DataRaptors, and Integration Procedures. A clear, predictable naming standard reduces ambiguity for developers, admins, and release engineers when diagnosing issues, performing deployments, or reusing components across projects.

General principles

Keep names concise, descriptive, and machine-friendly. Use a consistent prefixing and versioning scheme, avoid spaces and special characters, and separate human-facing labels from API names.

Recommended structure

Use this generic pattern for major components:

<Prefix>_<ProjectCode>_<FeatureOrObject>_<ActionOrPurpose>_v<MajorMinor>

Where:

  • Prefix: short identifier for type (see Component prefixes below)
  • ProjectCode: short project or product code (e.g., CRM, QUO)
  • FeatureOrObject: business area or SObject (Account, Quote)
  • ActionOrPurpose: what it does (Create, Read, Update, Search)
  • v<MajorMinor>: version (v01, v02, v1.0 for major changes)

Component prefixes

Using short, consistent prefixes makes it easy to scan lists in the OmniStudio console or a metadata repository. Examples:

  • OS — OmniScript (e.g., OS_CRM_Account_Create_v01)
  • OSF — OmniScript Fragment (reusable part)
  • DR — DataRaptor (Extract/Load/Transform) (e.g., DR_CRM_Account_Read_v01)
  • IP — Integration Procedure (e.g., IP_CRM_CreateAccount_v01)
  • AC — Action (OmniScript Action element) or Custom Action wrapper
  • SR — Salesforce Resource or Apex REST wrapper if required

OmniScript (top-level) naming

Top-level OmniScript names should clearly state the solution area and intended user flow. Use the OS_ prefix and include a short version suffix:

OS_FIN_Claims_Submission_v02

Key rules:

  • Use underscores to separate logical parts, not spaces.
  • Keep names under 80 characters where possible to avoid UI truncation.
  • Use semantic versioning for breaking changes.

OmniScript element API names (Steps, Blocks, Inputs)

Each element in the OmniScript has an API name (developer name) and a Label (display). Follow these rules for element API names:

  • Use camelCase or snake_case consistently (pick one). Example: customerInfoStep or customer_info_step.
  • Append a suffix indicating the element type when it improves clarity: _step, _block, _input, _select.
  • Keep labels friendly and human-readable; labels can include spaces and punctuation.

Example element names:

customerInfo_step

billingAddress_block

email_input

DataRaptor and Integration Procedure naming

Because OmniStudio relies heavily on DataRaptors and Integration Procedures, use the DR_ and IP_ prefixes and describe the intent:

DR_CRM_Account_Read_v01 — DataRaptor Extract to read Accounts

IP_CRM_CreateAccount_v01 — Integration Procedure to orchestrate account creation

Action and Data Source names

Name action elements to indicate the operation and the back-end they target:

callIP_CreateAccount

drExtract_PolicyDetails

Variables, JSON keys and Data JSON naming

Use camelCase for JSON keys and variable names to align with JavaScript conventions and integration payloads. Avoid spacing and special characters.

{ "customerId": "", "policyNumber": "" }

Versioning and deprecation

Include the version in the component name and increment for breaking changes. For non-breaking tweaks (labels, help text), prefer not to bump the version unless tracking policies require it.

Example: OS_CRM_Case_Create_v03 — when v03 includes a new API-based step that changes the data contract.

Naming checklist for developers

  • Prefix by component type (OS, DR, IP, AC)
  • Include Project or Product code
  • Include object or functional area
  • Describe action/purpose
  • Append version (v01, v02)
  • Use consistent casing and separators across the org

Examples

Realistic examples you can adopt:

  • OS_QUO_QuoteCreation_v01
  • DR_QUO_Quote_Read_v01
  • IP_QUO_Pricing_Calculate_v02
  • OSF_QUO_AddressFragment_v01

Benefits of following these conventions

Consistent naming reduces onboarding time, improves searchability in metadata lists, simplifies deployment and CI/CD, and enables faster troubleshooting during incidents.

Quick governance tips

  • Document the conventions in your project README or Confluence space.
  • Enforce rules via code review/checklist during PRs or metadata reviews.
  • Keep a registry of active OmniScripts, DataRaptors, and IPs with owners and versions.

Following these OmniScript naming conventions will make your OmniStudio implementations more scalable, maintainable, and team-friendly.