Why OmniScript naming conventions save your sanity
If you have ever opened a Salesforce Industries org only to find fifty versions of “Test_Script” or “New_Process_v2”, you know exactly why OmniScript naming conventions are a big deal. I have spent way too many hours digging through metadata trying to figure out which DataRaptor belongs to which flow. It is a mess that slows everyone down.
When we talk about OmniScript naming conventions, we are not just being picky about labels. We are building a system so that any developer on your team can look at a list of assets and know exactly what each one does without clicking into it. It is about making the org searchable and predictable. Trust me, your future self will thank you during a late-night deployment.
The core pattern for OmniScript naming conventions
In my experience, the best naming patterns are the ones that people actually use. If it is too complex, people skip it. I usually recommend a structure that moves from the broad “who” to the specific “what”. A solid template looks like this: {Org}_{Project}_{Type}_{Module}_{Description}_v{Version}.
Let’s look at a real example: ACME_SALES_OS_LeadCapture_CreateLead_v1.0. Just by looking at that string, you know it belongs to the Sales project, it’s an OmniScript, it handles Lead Capture, and specifically the creation step. It is clean, it is searchable, and it keeps your workspace organized.
Prefixes and type codes
You want to be able to filter your assets quickly. Using short, two-letter codes for different OmniStudio elements is the easiest way to do this. Here are the ones I use on every project:
- OS – OmniScript (e.g.,
CS_RET_OS_CancelService_v2.1) - DR – DataRaptor (Extract, Transform, or Load)
- IP – Integration Procedure
- SR – Sub-OmniScript or reusable fragments
This is especially helpful when you are trying to find the OmniScript naming conventions for related assets. If your OS is named SALES_Quote_Create, your DataRaptor should probably be SALES_DR_GetQuoteData. Keeping these consistent across the board makes debugging much faster.
Naming elements inside the designer
One thing that trips people up is forgetting to name the elements inside the script. I’ve seen teams leave everything as “Step1” or “DataRaptorAction1”. That is a recipe for disaster when you need to map data. Use clear, action-oriented names like Step_CustomerInfo or Action_PostToSlack. If you are also working with FlexCard naming conventions, you will see how much easier it is to link components when the names actually make sense.
Best practices for team governance
Look, a naming convention only works if everyone follows it. I’ve seen great standards fall apart because they weren’t documented or enforced. Here is the thing: you should include these rules in your PR reviews. If a name doesn’t match the pattern, it doesn’t get merged. It sounds harsh, but it’s the only way to keep a large org from turning into a graveyard of “Test” scripts.
Pro tip: Keep a shared “Prefix Registry” in your project documentation. This prevents two different teams from using the same abbreviations for different modules.
If you are preparing for a senior Salesforce developer interview, being able to explain why you chose a specific naming structure shows that you care about long-term maintenance, not just getting the code to work today.
Handling versions and environments
Don’t bake environment names like “DEV” or “UAT” into the permanent name of the script. Use the versioning field that Salesforce Industries provides. If you need to create a temporary branch for a specific feature, a suffix like _feat_DiscountFix is fine, but make sure it gets cleaned up before it hits production. Just like with Salesforce Flow best practices, keeping your production environment clean of “temp” assets is vital for performance and clarity.
Key Takeaways for OmniScript Naming
- Be consistent: Use the
{Org}_{Project}_{Type}_{Description}pattern every single time. - Use prefixes: Stick to OS, DR, and IP to make filtering easy in the designer.
- Action-oriented descriptions: Use names like
UpdateAddressinstead ofScript1. - No special characters: Stick to underscores and alphanumeric characters to avoid API issues.
- Enforce it: Make naming part of your code review process.
Getting the team on board
So how do you actually start? Don’t try to rename everything at once. Start with the next new module you build. Write down your OmniScript naming conventions on a single page and share it with the team. Once people see how much easier it is to find their work, they will start doing it naturally. It is one of those small changes that has a massive impact on your day-to-day productivity. Start small, stay consistent, and keep your org clean.