Overview
OmniScript naming conventions ensure consistency, readability, and maintainability for Salesforce Industries (Vlocity) OmniScripts. Well-defined names make it easier for teams to discover, reuse, and support OmniScripts, related elements (DataRaptors, Integration Procedures), and internal steps.
Core Principles
Use clear, descriptive, and consistent patterns. Keep names short but meaningful, use predictable prefixes, include module or domain context, and add version/environment markers when needed.
Recommended Naming Pattern
Common template (adjust to your org-standard):
{OrgPrefix}_{Project}_{Type}_{ModuleOrFeature}_{Description}_v{Major}.{Minor}
Example:
CS_ACQ_OS_LeadCapture_CreateLead_v1.0
Prefixes and Type Codes
Use short type codes so elements can be identified quickly:
OS
— OmniScript (e.g.,CS_SALES_OS_QuoteRequest_v2.0
)DR
— DataRaptor (Extract/Transform/Load) (e.g.,CS_SALES_DR_AccountFetch_v1.0
)IP
— Integration Procedure (e.g.,CS_SALES_IP_CRMSync_v1.2
)ES
— Element Script / JS step (if used)SR
— Subroutine or Sub-OmniScript (for reusable fragments)
Module or Feature Segment
Include the functional area or product line (e.g., ACQ
for acquisition, RET
for retention, Billing
). This helps locate relevant artifacts quickly.
Descriptions and Detail
Use short camel-case or underscore-delimited descriptions to explain purpose. Avoid overly generic words like “Helper” or “Test”. Prefer action-oriented descriptions:
CreateLead
,UpdateBillingAddress
,ValidateSSN
Versioning and Environment Suffixes
Include a version suffix to manage changes and deployments:
_v1.0
, _v1.1
. For temporary branches or environment-specific tweaks, use a short suffix (avoid embedding environment names permanently):
_temp
or for branches _feat/discountFlow
(but prefer to merge and finalize names before production).
Step & Element Naming inside OmniScripts
For steps and elements within an OmniScript, keep names descriptive and short. These are visible to admins and developers in the OmniStudio designer:
- Step labels:
Step_CustomerInfo
,Step_Pricing
- DataRaptor elements:
DR_GetAccount
,DR_SaveQuote
- Integration actions:
IP_VerifyIdentity
- Action elements:
Action_CreateCase
,Action_SendEmail
Character Rules & Limitations
Follow these safe practices:
- Use only letters, numbers, and underscores. Avoid spaces and special characters that may break APIs.
- Keep names under platform limits (be mindful of field/API name length).
- Prefer PascalCase or underscores for readability:
CS_ACQ_OS_LeadCapture
orCS_ACQ_OS_Lead_Capture
.
Example Naming Conventions Table (Quick Reference)
(Shown here as examples)
CS_ACQ_OS_LeadCapture_CreateLead_v1.0
CS_ACQ_DR_AccountFetch_v1.0
CS_ACQ_IP_CRMSync_v1.2
CS_RET_OS_BillingUpdate_UpdatePaymentMethod_v1.0
Governance Checklist
Before naming/publishing OmniScripts, validate:
- Does the name include OrgPrefix and Project/Module?
- Is the type code present (OS, DR, IP)?
- Is the description concise and meaningful?
- Is versioning applied if this is a change or new release?
- Does it avoid prohibited characters and follow length constraints?
Tips for Teams
1) Create a short naming standards document and incorporate it into your CI/CD or deployment checklist. 2) Use a shared prefix registry to avoid collisions. 3) Add descriptive comments in the OmniScript documentation and repository so reviewers can confirm names during code review.
Sample Interview Answer (Concise)
Use clear, consistent names with a pattern like {Org}_{Project}_{Type}_{Module}_{Description}_v{X.Y}
. Apply short type prefixes (OS, DR, IP), include module context, keep descriptions action-oriented, use versioning, and avoid special characters. This ensures maintainability and easier discovery across teams.
Conclusion
Consistent OmniScript naming reduces confusion and speeds development. Agreeing on and enforcing a simple convention (and documenting it) is the highest-impact best practice for any Salesforce Industries implementation.
Leave a Reply