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.
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.
Glossary
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
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
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]
Boomi Component Naming Guideline #3: 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
Naming Structure
[application] type of data + type of profile (optional)
or
[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
Naming Structure
[application]Operation + Object + Function Name
or
[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
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
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
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
Naming Structure
property names + “,” + property names (repeating)
or
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
Naming Structure
data field + logical operator
or
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
Naming Structure
data fields + logical operators
or
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 
& 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
Naming Structure
[application] (optional) type of data
or
[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
or
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
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
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
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
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
Naming Structure
property names + “,” + property names (repeating)
or
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