Why naming conventions matter for OmniScript
Consistent OmniScript naming conventions improve maintainability, make collaboration easier across teams, and speed up troubleshooting for Salesforce Industries (Vlocity) implementations. Well-chosen names help identify purpose, scope, and dependencies (DataRaptors, Integration Procedures, Apex, etc.).
General rules (apply project-wide)
Use these cross-cutting conventions for all Salesforce Industries components that interact with OmniScript:
– Use a short project or org prefix (e.g., CS, ACME) to avoid collisions across teams.
– Use a resource-type prefix for quick identification: OS for OmniScript, DR for DataRaptor, IP for Integration Procedure, TS for TestSuite or Test classes.
– Use underscores _ to separate logical parts of the name. Avoid spaces and special characters.
– Use PascalCase or TitleCase for the functional portion (human readable) and keep version suffixes at the end: v1, v2.
– Keep names concise but descriptive. Include the primary object or domain and the action being performed.
Naming pattern examples
Recommended canonical pattern for OmniScripts:
ProjectPrefix_OS_FunctionOrObject_Purpose_vX
Examples:
CS_OS_AccountOnboarding_Create_v1
ACME_OS_Case_Routing_Assisted_v2
Component-specific conventions
Below are suggested conventions for items commonly referenced by OmniScript:
OmniScript (script-level)
Pattern: ProjectPrefix_OS_[Object|Domain]_[Action|Flow]_vX
Example: CS_OS_PolicyRenewal_Express_v1
OmniScript Elements (Steps, Inputs, DataJSON variables)
Element names are used in JSON, mapping, and DataRaptor/Integration calls. Choose consistent variable naming to avoid confusion:
– Use camelCase for element names and variables: applicantFirstName, billingAddress.
– For Step or Block names, include the role: personalInfoStep, paymentDetailsBlock.
– When mapping to DataRaptor or external systems, align element names to API/field names when possible to simplify mapping.
DataRaptor
Pattern: ProjectPrefix_DR_[Object]_[Action]_vX
Examples: CS_DR_Account_Extract_v1, ACME_DR_Case_Load_v2
Integration Procedure
Pattern: ProjectPrefix_IP_[System]_[Operation]_vX
Examples: CS_IP_SF_CreateAccount_v1, ACME_IP_ExternalSvc_GetRates_v1
Apex Classes (if used by OmniScript)
Pattern: ProjectPrefix_Apex_[Purpose]_[Helper|Service]_vX
Example: CS_Apex_OmniScriptDataMapper_Service_v1
Versioning strategy
– Always append a version suffix (e.g., _v1, _v2) to indicate iterations. Use semantic versioning only if you have multiple breaking changes per release.
– Avoid adding environment names (DEV/UAT/PROD) into component names — manage environments through CI/CD pipelines, branches, or org-specific metadata management.
Additional best practices
– Avoid using special characters or spaces — only letters, numbers and underscores.
– Use a naming registry or spreadsheet to track all major OmniScript, DataRaptor, and Integration Procedure names per project. Include owner, dependencies, and brief description.
– Keep labels friendly/human-readable for admins and end-users, and keep the developer name (API name) following the convention above.
Quick reference examples
CS_OS_CustomerOnboarding_Starter_v1
CS_DR_Contact_Extract_v1
CS_IP_SF_CreateContact_v1
CS_OS_CustomerOnboarding_personalInfoStep
Summary
Consistent naming conventions for OmniScript and related components reduce errors, speed onboarding, and make integrations more predictable. Define a simple, project-wide convention (prefix, resource-type, functional name, version), document it, and enforce it through code review and a registry.