OmniStudio Naming Conventions: A Guide to Consistency and Clarity

Effective naming conventions are foundational to maintaining consistency, clarity, and efficiency within any Salesforce implementation. In the context of OmniStudio, where reusable components such as OmniScripts, Integration Procedures, and DataRaptors (DataMappers) play a crucial role, a standardized approach to naming ensures seamless collaboration, streamlined development, and ease of maintenance. This article outlines best practices for naming conventions, focusing on avoiding redundancy, enhancing readability, and reducing the risk of errors associated with overlapping names or unclear designations.

Naming Convention Guidelines

This article aims to establish a unified naming convention for various clouds within Salesforce Industries. A standardized naming protocol is critical for minimizing errors related to reusable components—such as OmniScripts, Integration Procedures, Data Mappers and Flex Cards — that may otherwise share identical names. By adopting these conventions, users can enhance clarity and ensure easy identification and understanding of each object and its purpose.

Consistency in naming and coding is essential to avoid duplication of logic and code. As a best practice, differentiation should be avoided unless necessary, and clear descriptions or specifications should always accompany component names.

For OmniScripts, Integration Procedures (Type and Subtype), and DataRaptors (API Name), it is essential to refrain from using underscores (_). Following this convention ensures uniformity and reduces confusion when working with these standard objects.

Naming conventions of main objects

The name of the main object (OmniScripts, DataRaptors, Integration Procedures and FlexCards) will be as follows:<object type code><functional description> where 

• <object type code> will depend on the object type (see table below)  
• <functional description> will be a brief description of the functionality covered by the object

Object	Object Type Code
Integration Procedure	IP
OmniScript	OS
DataRaptor Extract	DRE
DataRaptor Post	DRP
DataRaptor Transform	DRT
Decision Matrix	DM
Expression Set	ES
Flex Card	FC
Flyout	FO

*Note that it is important that names do not contain spaces..

SFI Object Elements

In “OmniScript Designer” and “Integration Procedures” each object must have a unique identifier to ensure that every element name is distinct. While Salesforce Industries (SFI) enforces uniqueness within an OmniScript, it does not validate uniqueness across other OmniScripts, which can lead to issues when OmniScripts are reused. To prevent such conflicts, a consistent naming format is required for single object elements in OmniScripts and Integration Procedures.

The naming convention for these elements is as follows:

<element type code>_<attribute code><suffix (if required)>

• <element type code>: A concise functional description of the element, without spaces.
• <attribute code>: A reference to the attribute to which the field delivers data.
• <suffix (if required)>: An optional addition used in cases where the attribute may refer to multiple objects or accounts (e.g., name, address, etc.).

By adhering to this naming structure, you can ensure clarity, consistency, and interoperability when designing and managing OmniScripts and Integration Procedures.

The following table shows structure element type codes to be used:

Element	Structure Element Type	Structure Element Type Code
Actions	Expression Set Action	ES
	DataRaptor Extract Action	DRE
	DataRaptor Post Action	DRP
	DataRaptor Transform Action	DRT
	Delete Action	DEL
	DocuSign Envelope Action	ENV
	DocuSign Signature Action	SIGN
	Done Action	DONE
	Email Action	EMail
	HTTP Action	HTTP
	Integration Procedure Action	IP
	Intelligence Action	INTL
	List Action	LIST
	Decision Matrix Action	LU
	OmniForm	OmniForm
	Navigation Action	NAV
	PDF Action	PDF
	Remote Action	RA
	Response Action	RES
	Review Action	RVW
	Set Errors	ERR
	Set Values	SV
	Submit	Submit
Display	Line Break	BRK
	TextBlock	TB
Functions	Aggregate	Aggr
	Formula	FRML
	Geolocation	GEO
	Messaging	MSSG
Groups	Block	Blck
	Action Block	AB
	Edit Block	EBlck
	Radio Group	RGrp
	Step	STP
	Type Ahead Block	TYP
	Cache Block	CACHE
	Conditional Block	COND
	Try Catch Block
Inputs	Checkbox	CHK
	Currency	CUR
	Custom Lightning Web Component	LWC
	Date	DAT
	Date/Time	Date/Time
	Disclose	Disclose
	Email	Email
	File	File
	Filter	Filter
	Image	IMG
	Lookup	Lookup
	Multi-select	Mselect
	Number	NUM
	Password	Pass
	Radio	RAD
	Range	Range
	Select	SEL
	Signature	SIG
	Telephone	Phone
	Text	TXT
	Text Area	TA
	Time	TIME
	URL	URL

Why Naming Conventions Matter | Key Takeaways

Establishing a robust naming convention at the start of every Salesforce Industries (SFI) project is a best practice that ensures consistency and clarity from the outset. By defining these standards early, teams can avoid confusion, reduce errors, and create a strong foundation for seamless collaboration and scalability throughout the project lifecycle. This proactive approach also supports the reusability of components like OmniScripts and Integration Procedures, enabling smoother integrations and more efficient maintenance in the long term.

Adopting standardized naming practices helps reduce errors, streamline development, and enhance the reusability of components. A well-defined naming strategy not only simplifies collaboration but also ensures long-term scalability and maintainability, enabling organizations to leverage the full potential of OmniStudio with confidence and precision.