This document outlines a comprehensive set of Boomi Component Naming Standards that will allow for better integration readability, maintenance, and troubleshooting. While there are many different naming conventions that can be adopted with pros and cons to each set, it is very rare to have the naming convention fully documented in one place. Most guidelines lack a consistent naming structure, and while it will dictate how a component should be named, it will often not explain the methodology behind it. This leaves developers following a guideline that they don’t fully comprehend, which results in them needing to reference the guideline frequently or unknowingly deviate from the convention. This set of Boomi Component Naming Guidelines will prevent that from happening by providing a multitude of examples and options for Boomi component naming as well as explanations on when to utilize each option.

CTA Dell Boomi Component Naming Guidelines

It is impossible to cover every scenario, but this document can be used as a solid foundation to build upon and create a naming convention that will fit your organization’s needs. Please reach out to us if you find this Boomi Component Naming convention helpful or would like to explore the other naming conventions.


1. CRUD – In computer programming, create, read, update, and delete (CRUD) are the four basic functions of persistent storage. Alternate words are sometimes used when defining the four basic functions of CRUD, such as retrieve instead of read, modify instead of update, or destroy instead of delete.

2. Environment – The environment denotes if an application/system is used for development, testing, user acceptance testing, or production. In Boomi, it is recommended that names be shortened including environments.

  • Dev – Development
  • Test – Test
  • QA – Quality Assurance
  • UAT – User Acceptance Testing
  • Prod – Production

3. Profile Types – There are different profile types within Boomi that the data can be transformed from and to. These profile types will be referenced in the names at times but shortened to the following.

  • FF – Flat File
  • DB – Database
  • XML – Extensible Markup Language
  • JSON – JavaScript Object Notation
  • EDI – Electronic Data Interchange

4. Dynamic Properties – Dynamic process and document properties are variables that can be defined at run time to store data. They only have values while the process is executing and is de-allocated when the process completes. There are two type of Dynamic properties.

  • DDP – Dynamic Document Property
  • DPP – Dynamic Process Property

5. Cross Reference Tables – Cross table contain pre-defined lookup key pairs and will be shortened to XREF when referencing a cross-reference table.

6. Exception Types – There are two types of exceptions within Boomi that can be thrown, and they affect the behavior of the try catch shape and process data flow.

  • DE – Document Error
  • PE – Process Error

7. Message Actions – The message shape can be a powerful tool in data manipulation as it allows you to extract or transform data freely within Boomi. Here is a list of the common actions used to aid in naming the message shape.

  • Extract – Grabbing pieces of data from a document and using that as your document going forward in the branch.
  • Append – Appending additional data to the end of each document.
  • Prepend – Adding data to the beginning of each document.
  • Combine – Combine all documents into one document.
  • Build – Grabbing multiple pieces of data from the document, metadata, and other data sources to construct a new data document.
  • Transform – Changing the document data type from one file format to another.

XTIVIA’s Boomi Component Naming Guidelines

Boomi Component Naming Guideline #1: Process Name
Boomi Component Naming Guidelines_ Process Name

Naming Structure

[Source System(s)]+ function + type of data + action performed [destination system(s)]

Explanation & Examples

Simple Example.

  • [SF] Send Customer Accounts [Hybris]

Naming processes with multiple data sources/destinations.

Example with multiple data systems. Note that commas are used to separate data systems within the square brackets

  • [SF] Send Customer Accounts [Hybris, SAP]

Naming processes with more than 3 data sources/destinations.

Example with many data systems. Note that we list the primary data system, with a “+” indicating that there are more data systems involved (three or more).

  • [SF] Send Customer Accounts [Hybris+]
  • [SF+] Send Customer Accounts [Hybris]

Naming processes with CRUD operations.

Optional Crud notation to be utilized for more complex actions performed. In the example below, we would be performing a Create and an Update. Please note that we leave the action description up to the discretion of the integration developer. They can list the “main” action being performed or be more specific as needed.

  • [SF] Send Customer Accounts CU [Hybris]

Naming processes with drop off/jump points.

This naming convention is to note the true data destination or source in your process name. If your process is picking up data from an SFTP, but the true data source is a real system, then you should denote that in the name via a “-“. The example below shows that we’re sending the data to a system called Hybris, but we’re dropping it off on an SFTP server for Hybris to consume.

  • [SF] Send Customer Accounts [Hybris-SFTP]

Naming processes and sub-processes with multiple data systems.

If your process is complex and has a master and sub-process design, then the master process should denote all data sources or data destinations. Here is an example we used where the master process denotes Hybris and SAP as the data destination, and the sub-process denotes that the data destination it is sending to.

  • [SF] Send Customer Accounts [Hybris, SAP]
    • SUB Send Customer Accounts [Hybris]
    • SUB Send Customer Accounts [SAP]

Boomi Component Naming Guideline #2: Sub-process Name
Boomi Component Naming Guidelines_ Sub-process Name

Naming Structure

SUB + function + type of data + action performed [destination system if there is any]

Explanation & Examples

Simple Example of a data pass-through process that does data manipulation

Helper sub-processes that only does data manipulation or calculations should not have the data source and destinations within it because it does not query data, and it does not send the data anywhere except back to the parent process.

  • SUB De-dupe Customer Accounts by Id
  • SUB Build HTML Email Body
  • SUB Calculate Order Id From Invoice Data

Example of a sub-process that generates data.

Sub-processes that query/generate data should denote where the data is coming from. The first example is descriptive naming by filter. The second example is the CRUD operation format.

  • SUB [SF] Get Customer Accounts by Date
  • SUB [SF] Customer Accounts R

Full Example with Parent Process.

  • [SF] Send Customer Accounts [Hybris]
    • SUB [SF] Get Customer Accounts by Date

Example of a sub-process that sends data to a destination.

If a sub-process receives data from a parent process (data passthrough) and then sends it to destination, then the data source should not be listed in the sub-process, only the data destination. The first example is descriptive naming by action. The second example is the CRUD operation format.

  • SUB Create/Update/Delete Customer Accounts [Hybris]
  • SUB Customer Accounts CUD [Hybris]

Full Example with Parent Process.

  • [SF] Send Customer Accounts [Hybris]
    • SUB Create/Update/Delete Customer Accounts [Hybris]
Want a downloadble PDF verison of this article to keep on hand or share with others? Download Here >

Boomi Component Naming Guideline #3: Connector Name
Boomi Component Naming Guidelines_connector name

Naming Structure

[Source System/Application] + (usage) + environment

Explanation & Examples

Data systems should be shortened for easier naming and searching, i.e., Salesforce should be “SF,” Workday should be “WD,” NetSuite should be “NS,” etc.

  • SAP
  • SAP-DB
  • SF

Storing connection information for reference and testing/data recovery.

There will be times where you need to store the credentials of the connector for different environments for testing/data recovery purposes so that they can be re-run on the canvas easily. This is the only time when the environment descriptor should be used.

  • SAP Dev
  • SAP Prod
  • SF Staging
  • SF QA

Boomi Component Naming Guideline #4: Profile Name
Boomi Component Naming Guidelines_Profile name

Naming Structure

[application] type of data + type of profile (optional)


[application] type of data + Parameters + type of profile (optional)

Explanation & Examples

Simple Example

If Boomi is building the profile for you via WSDL or JSON definition, then you should use the auto-generate profile name.

  • AtomSphere API ExecutionRecord QUERY Response

You can shorten the system/application name and put it into brackets. The optional profile type can be added if desired, but it is not required.

  • [AS_API] ExecutionRecord QUERY Response XML

Naming Manually Created Profile

If you’re building the profile yourself by hand or importing the data via CSV/XML without a WSDL, then you should follow the naming convention outlined here.

  • [SAP] Customer Accounts

Adding Parameters

Example with parameters (Note parameters are not always available given profile types. For example, XML does not have parameters, but Database does.)

  • [SAP-DB] Customer Accounts by Id, Date

Boomi Component Naming Guideline #5: Operation Name
Boomi Component Naming Guidelines_operation name

Naming Structure

[application]Operation + Object + Function Name


[application]Operation + Object + parameter

Explanation & Examples

Your operation should denote the system it is working with, the object/data and the operation.

  • [SF] Create/Update Customer Account
  • [SF] Customer Account CU

Example using parameters

  • [SAP-DB] Customer Accounts by Id

Boomi Component Naming Guideline #6: Map Name
Boomi Component Naming Guidelines_map name

Naming Structure

[source system (optional)] action performed + type of the data [destination system]

Explanation & Examples

The map name should indicate what transformations are being done to the data. Maps that are purely for transformation purposes do not need the systems or profile type in the name. These types of maps should state the data it is working with and the transformation it is performing.

  • De-Dupe Customer Data by Customer Name
  • Calculate Parent Account Id

Maps that transform the data from one format to another should have the data transformation in the name.

  • Customer Data FF to XML

Maps that are transforming the data to a specific format, either from or to a system profile, should have the system and type in the name.

  • [SAP] Customer Data XML to FF [Hybris]

Boomi Component Naming Guideline #7: Function Name
Boomi Component Naming Guidelines_function name

Naming Structure

(optional) return type + Descriptive function name

Explanation & Examples

Simple Example

  • (Invoice #) Calculate/Store Invoice Number in DDP
  • Build Order # From Order Type & Inventory #
  • Lookup Material Serial # by Material Id

Boomi Component Naming Guideline #8: Filter Expression Name
Boomi Component Naming Guidelines_filter expression name

Naming Structure

field name + logical operator

Explanation & Examples

Simple Example

Filter expression names should include the field they are referencing and the logical operator it is using for comparison. This is so when you’re looking at the parameters tab on the operation you understand what the filters are without having to click into each field.

  • lastModified >=
  • Customer_Id =
  • Material_Name starts with
  • transDate Between

Multiple fields with the same name on different objects

Sometimes due to a join or how objects are related to each other, there can be multiple fields with the same name but under different object types. In cases like this, the object should be referenced in the filter expression along with the field separated by a “.” or a “:”.

  • Customer.createdDate =
  • Account: createdDate =
  • Transaction.tranId starts with
  • Transaction: tranId starts with

Boomi Component Naming Guideline #9: Dynamic Properties

Naming Structure

acronym + “_” + data being stored

Explanation & Examples

Dynamic Properties are commonly used within Boomi integrations in the Set Properties, Map, Map Functions and Custom Scripting shapes. It is very important that they follow the proper naming convention. They are case sensitive as well, and special characters (i.e., “#,” “@,” “$,” etc.) should not be used in the names.

Dynamic Document Property

  • DDP_Invoice_Num
  • DDP_invoiceNum
  • DDP_Trans_Id
  • DDP_transId

Dynamic Process Property

  • DPP_Rerun_Flag
  • DPP_rerunFlag

Boomi Component Naming Guideline #10: Set Properties
Boomi Component Naming Guidelines_set properties

Naming Structure

property names + “,” + property names (repeating)


property group name

Explanation & Examples

Set Dynamic Properties

Set properties shape is canvas only shapes and are not separate components. This makes it much harder to search for Dynamic Document or Process Properties that get their values within these shapes. By putting the dynamic property names in the shape name, we can do a “CTRL + f” in the browser to search the canvas and see which set property shape assigns a value to that variable.

  • DDP_Invoice_Num, DDP_Trans_Id, DPP_Rerun_Flag
  • DDP_ invoiceNum, DDP_ transId, DPP_ rerunFlag

Set Property Group

If the set properties shape isn’t setting a dynamic property but is setting a connector attribute (email to address, sftp directory, disk file name), then the name should be the grouping.

  • Email Properties
  • SFTP Properties
  • Execution Properties

Boomi Component Naming Guideline #11: Decision
Boomi Component Naming Guidelines_decision

Naming Structure

data field + logical operator


question statement

Explanation & Examples

Single field decision

  • DDP_Material_Num not empty
  • customerId is null
  • Order_Qty > 0

Question Statement aka Lookup decision

  • Customer exists in SAP?
  • Item SKU exists in Item Doc Cache?
  • Process ID in XREF Table?

Boomi Component Naming Guideline #12: Business Rule
Boomi Component Naming Guidelines_business rule

Naming Structure

data fields + logical operators


validation statement

Explanation & Examples

A business rule shape is a more complex decision shape. It can contain multiple logical expressions, so naming a business rule can be tricky. If it’s only a field or two that you’re validating, then you can list the field and logical operation in the name like a filter/decision.

Simple Business Rule

  • Inventory Item Count > 0
  • Order Detail Lines not empty

Complex Business Rule

The naming guideline is for more complex business rule that check multiple fields/grouping of “AND” and “OR” comparisons should use a generalized validation statement with the most critical condition being in the name.

  • Order Item SKU Validation
  • Verify Employee Data
  • Inventory Location Validation

Boomi Component Naming Guideline #13: Process Routes Dell Boomi Component Naming Guidelines_process routes & Route Dell Boomi Component Naming Guidelines_route

Naming Structure

route + data system (optional) + data field that is being used to route

Explanation & Examples

  • Route by DDP_Order_Type
  • Route by Customer Type
  • Route by SAP.accountType

Boomi Component Naming Guideline #14: Cross Reference
Boomi Component Naming Guidelines_cross reference

Naming Structure

[application] (optional) type of data


[application] (optional) data object

Explanation & Examples

XREF with Source System

For regular XREF tables that are referencing a system/application meta values, the source application/system should be listed in the name.

  • [SAP] Material Types Id
  • [NS] Vendor Categories Name and Id
  • [SF] Account Type Drop Down

XREF without Source System

  • Material Types Selection
  • Warehouse Names to Ignore

Boomi Component Naming Guideline #15: Tracked Fields

Naming Structure

[application] (optional) + “.” + field name


normalized field name

Explanation & Examples

Tracked fields are used to record values from the data document in process reporting and can be used across multiple processes.

With Source System

  • SAP.accountNumber
  • NS.internalId
  • SF.Order_Id

Without Source System

  • Document Order ID
  • Purchase Order Num
  • Shipment Order Num

Boomi Component Naming Guideline #16: Document Cache
Boomi Component Naming Guidelines_document cache

Naming Structure

[application] (optional) + type of data + profile type (optional)

Explanation & Examples

The document cache should describe what is being stored in it with the application/profile type being optional.

With Application/System

  • SF.customerRecords XML
  • SAP-DB.accounts
  • NS.purchaseOrders JSON
  • WD Approved Warehouse Locations

Without Application/System

  • Successful Execution Records FF
  • Valid Inventory Items
  • Warehouse Locations
  • Customer Accounts

Boomi Component Naming Guideline #17: Data Process
Boomi Component Naming Guidelines_data process

Naming Structure

data processing action + type of data (optional) + “,” (repeat as needed)

Explanation & Examples

The data processing shape has many different functions, so the name should reflect the actions being performed, separated by a “,” (comma).

Single Action

  • Split by Order Id
  • Combine by Item Name
  • Zip Employee Photos
  • PGP Encrypt Data

Multiple Actions

  • Combine by Item Name, Zip Data, PGP Encrypt Data

Boomi Component Naming Guideline #18: Exception
Boomi Component Naming Guidelines_exception

Naming Structure

exception type + “:” + action + type of data (optional)

Explanation & Examples

The exception shape affects the integration try-catch behavior, so the name should indicate if it’s throwing a process error or a single document error.

  • DE: Create Item Receipt
  • PE: Update Customer Account
  • PE: Item Validation Force Stop

Boomi Component Naming Guideline #19: Message
Boomi Component Naming Guidelines_message

Naming Structure

message action + type of data + profile type (optional)

Explanation & Examples

Without Profile Type

  • Build Email Body
  • Extract Customer Data
  • Append Footer Record
  • Prepend Header Columns
  • Combine Account Records

With Profile Type

When the profile type is present in the name, then data transformation is implied, and you do not need to put the word transform in the name.

  • Customer Records XML to FF

Boomi Component Naming Guideline #20: Message
Boomi Component Naming Guidelines_message

Naming Structure

property names + “,” + property names (repeating)


property group name

Explanation & Examples

The notify shape is used for debugging and data logging, so the name should reflect the data that is being logged. This makes it easier to search for the notify shape in the process logs. It is very similar to the “Set Properties” shape in its naming convention, but it is used for logging instead of setting.

  • Invoice Num
  • DDP_ProcessName, Atom Id, DDP_StartDateTime

Property Group

When there are too many properties to list out in the name (4+), then the property group name should be used.

  • Email Properties
  • SFTP Properties
  • Execution Properties
Share This