Skip to main content

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

  1. 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.

  2. The Domain of the SHALL always be followed by a code indicating the type of the Flow, respecting the cases as follows:

    1. If the flow is a Screen Flow, the code SHALL be SCR.

    2. If the flow is a SubFlow, the code SHALL be SFL.

    3. If the flow is specifically designed to be a scheduled flow that runs in Batches, the code SHALL be BAT.

    4. 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 .

    5. If the flow is an Event Triggered flow, the code SHALL be EVT instead.

    6. If the flow is specifically designed to be a Record Triggered flow that ONLY handles email sends, the code SHALL be EML instead.

  3. 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.

  4. 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

  1. Any Query SHALL always start by Getfor any Objects, followed by an underscore, or FETCH for CMTD or Settings.

  2. 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.

  3. 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.

  4. 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.
Example of a readable Flow

 

Interactions

  1. 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.

  2. 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.

  3. 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.

 

Exmaple of a Screen containing a Text element

Screen Elements

  1. 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.

  2. Any formula SHALL always start by form followed by an underscore, followed by the data type returned, and an underscore.

  3. 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.
Note: This var name is CASE SENSITIVE.

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.

image-1644418003456.png

Screenshot from the Manager, with examples of Variables and Screen elements

Logics

  1. 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!

  2. 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.

  3. 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
Assignment: {!sObj_coll_OppProdtoCreate}  Add  {!sObj_This_OpportunityProduct}

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
Outcome one:
CHECK_PBESelected_Yes
Outcome two:
CHECK_PBESelected_No
Default Outcome: Catastrophic Failure

Check if at least one row was selected. Otherwise terminates to an error screen.

Decision to sort elements based on criteria

Decision: DEC_SortOverrides
Outcome one:
SortOverrides_Fields
Outcome two:
SortOverrides_Values
Outcome three:
SortOverrides_Full
Default Outcome: Catastrophic Failure

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
#1    Renny   Renny commented 2 years ago

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?

#2    Megalithe   Megalithe commented 11 months ago •  Updated 11 months ago by Megalithe

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?

Back to top