Flow Naming Conventions
All prefixes apart from Screen Subelements are ALL CAPS. All Names after a prefix are CamelCase with no underscores outside of where indicated. The table at the bottom contains examples of most cases.
Meta-Flow Naming
-
A Flow name SHALL always start by the name of the Domain from which it originates, followed by an underscore.
In most cases, for Flows, the Domain is equivalent to the Object that it is hosted on.
As per structural conventions, cross-object Flows should be avoided and reliance on Events to synchronize flows that do cross-object operations should be used. -
The Domain of the SHALL always be followed by a code indicating the type of the Flow, respecting the cases as follows:
-
If the flow is a Screen Flow, the code SHALL be SCR.
-
If the flow is a SubFlow, the code SHALL be SFL.
-
If the flow is specifically designed to be a scheduled flow that runs in Batches, the code SHALL be BAT.
-
If the flow is a Record Triggered flow, the code SHALL be TRG instead.
In addition, the flow name SHALL contain the context of execution, meaning either BEFORE or AFTER, followed by either Create , CreateUpdate , or Update . -
If the flow is an Event Triggered flow, the code SHALL be EVT instead.
-
If the flow is specifically designed to be a Record Triggered flow that ONLY handles email sends, the code SHALL be EML instead.
-
-
A Flow name SHALL further be named after the action being carried out in the most precise manner possible. For Record Triggered Flows, this is limited to what triggers it. See example table for details.
-
A Flow Description SHOULD always indicate what the Flow requires to run, what it does functionally, and what it outputs.
Type |
Name |
Description |
---|---|---|
Screen Flow |
QUOTE_SCR_AddQuoteLines |
A Screen flow that is used to override the Quote Lines addition page. Provides function related to Discount calculation based on Discounts_cmtd. |
Scheduled Flow |
CONTACT_BAT_SendBirthdayEmails |
A Scheduled flow that runs daily, checks if a contact is due a Birthday email, and sends it using the template marked Marketing_Birthday |
Before Update Flow, on Account |
ACCOUNT_TRG_BeforeUpdate |
Triggers Before-Update automations on Account. See details for list of functions. |
After Update Flow, on Account |
ACCOUNT_TRG_AfterUpdate |
Triggers After-Update automations on Account. See details for list of functions. Check SFL_Acc flows for actions taken. |
Record-triggered Flow on Opportunity. Fires a “Sales Finished” event once Opportunity is Closed Won and actions have been taken |
OPP_TRG_BeforeUpdate |
Triggers Before-Update automations on Opportunity. See details for list of functions. |
Event-Triggered Flow, creating Invoices, which triggers when a Sales Finished event gets fired |
INVOICE_EVT_SalesFinished |
Creates an Invoice and notifies Invoicing about the new invoice to validate based on Sales information |
Record-triggered Email-sending Flow, on Account. |
ACCOUNT_EML_BeforeUpdate |
Handles email notifications from Account based on record changes. |
Flow Elements
DMLs
-
Any Query SHALL always start by Getfor any Objects, followed by an underscore, or FETCH for CMTD or Settings.
-
Any Update SHALL always start by Updatefollowed by an underscore. If it Updates a Collection, it SHALL also be prefixed by Listafter the aforementioned underscore.
-
Any Create SHALL always start by Createfollowed by an underscore. If it Creates a Collection, it SHALL also be prefixed by Listafter the aforementioned underscore.
-
Any Delete SHALL always start by Delfollowed by an underscore. If it Deletes a Collection, it SHALL also be prefixed by Listafter the aforementioned underscore.
Type |
Name |
Description |
---|---|---|
Screen within a Flow |
Label: Select Price Book Entries Name: S01_SelectPBEs |
Allows selection of which products will be added to the quote, based on pricebookentries fetched. |
Screen that handles errors based on a DML within a Flow |
ERROR_GET_PBE |
Happens if the GET on Pricebook Entries fails. Probably related to Permissions. |
Text element in the first screen of the flow |
S01_T01 |
Fill with actual Text from the Text element - there is no description field |
DataTable in the first screen of the flow |
S01_LWCTable_Products |
May be inapplicable as the LWCs may not offer a Description field. |
Interactions
-
Any Screen SHALL always start by S, followed by a number corresponding to the current number of Screens in the current Flow plus 1, followed by an underscore.
-
Any Action SHALL always start by ACT, followed by an underscore. The Action Name SHOULD furthermore indicate what the action carries out.
-
Any APEX Action SHALL always start by APEX instead, followed by an underscore, followed by a shorthand of the outcome expected. Properly named APEX functions should be usable as-is for naming.
-
Any Subflow SHALL always start by SUB instead, followed by an underscore, followed by the code of the Flow triggered (FL01 for example), followed by an underscore, followed by a shorthand of the outcome expected.
-
-
Any Email Alert SHALL always start by EA, followed by an underscore, followed by the code of the Email Template getting sent, an underscore, and a shorthand of what email should be sent.
Screen Elements
-
Any variable SHALL always start by var followed by an underscore.
-
Any variable that stores a Collection SHALL always in addition start by coll followed by an underscore.
-
Any variable that stores a Record SHALL always in addition start by sObj followed by an underscore.
-
Any other variable type SHALL always in addition start by an indicator of the variable type, followed by an underscore.
-
-
Any formula SHALL always start by form followed by an underscore, followed by the data type returned, and an underscore.
-
Any choice SHALL always start by ch followed by an underscore. The Choice name should reflect the outcome of the choice.
Type |
Name |
Description |
---|---|---|
Formula to get the total number of Products sold |
formula_ProductDiscountWeighted |
Weights the discount by product type and calculates actual final discount. Catches null values for discounts or prices and returns 0. |
Variable to store the recordId |
recordId |
Stores the record Id that starts the flow.
Exempt from normal conventions because legacy Salesforce behavior. |
Record that we create from calculated values in the Flow in a Loop, before storing it in a collection variable to create them all |
sObj_This_OpportunityProduct |
The Opportunity Product the values of which we calculate. |
Logics
-
Any Decision SHALL start by DEC if the decision is an open choice, or CHECK if it is a logical terminator, followed by an underscore. The Action Name SHOULD furthermore be prefixed by Is, Can, or another adverb indicating the nature of the decision, as well as a short description of what is checked.
-
Any Decision Outcome SHALL start with the Decision Name without any Prefixes, followed by an underscore, followed by the Outcome.
-
The Default Outcome SHOULD be used for error handling and relabeled ERROR where applicable - you can relabel the default outcome!
-
-
Any Assignment SHALL always start with SET, ASSIGN, STORE, REMOVE or CALC (depending on the type of the assignation being done) followed by an underscore.
-
SET SHOULD be used for variable updates, mainly for Object variables, where the variable existed before.
-
ASSIGN SHOULD be used for variable initialization, or updates on Non-Object variables.
-
STORE SHOULD be used for adding elements to Collections.
-
REMOVE SHOULD be used for removing elements from Collections.
-
CALC SHOULD be used for any mathematical assignment or complex collection manipulation.
-
-
Any Loop SHALL always start with LOOP, followed by an underscore, followed by the description of what is being iterated over. This can vary from the Collection name.
Type |
Name |
Description |
---|---|---|
Assignment to set the sObj_This_OpportunityProduct record values |
SET_OppProdValues |
Sets the OppProd based on calculated discounts and quantities. |
Assignment to store the Opportunity Product for later creation in a collection variable |
Name: STORE_ThisOppProd |
Adds the calculated Opp Prod lines to the collvar to create. |
DML to create multiple records store in a collection sObj variable |
CREATE_OppProds |
Creates the configured OppProd. |
Decision to check selected elements for processing |
Decision: CHECK_PBESelected |
Check if at least one row was selected. Otherwise terminates to an error screen. |
Decision to sort elements based on criteria |
Decision: DEC_SortOverrides |
Based on user selection, check if we need to override information within the records, and which information needs to be overridden. |
Email Alert sent from Flow informing user of Invoice reception |
EA01_EI10_InvoiceReceived |
Sends template EI10 with details of the Invoice to pay |
2 Comments
I think the article can be more clear regarding the flow's label and API name naming conventions. Shouldn't the label be user-friendly, even though the user is likely an admin? In this case, the table below could include the name for those elements, such as the flow "FL01_AddQuoteLines" having "Add Quote Lines" as the label. Does that make sense?
Love the guidelines! @Renny, I concur with your feedback and this is the action I have taken in my org.
At the start, it is advised "All Names after a prefix are CamelCase with no underscores outside of where indicated" based on the casing in the doc I think the standard being recommended is actually pascal case https://stackoverflow.com/questions/41768733/camel-case-and-pascal-case-mistake
Regarding Choices - Do you feel its pertinent to define the choice data type in the API name? i.e. ch_text_* ch_number_* etc?