Best Practices for Naming Conventions in Salesforce Flows

Why Naming Conventions Matter in Salesforce Flows

Clear, consistent naming conventions make Flows easier to understand, maintain, and govern — especially in orgs with multiple admins and developers. Good names reduce onboarding time, speed troubleshooting, and prevent accidental edits or duplicate automation.

Core Principles

Apply these core principles when naming Flows and Flow elements:

• Be descriptive but concise: capture the Flow's purpose in a short phrase.
• Use a consistent structure: include object, action, trigger type, and environment.
• Prefer readability over cleverness: avoid abbreviations that aren’t universally understood.
• Include version or status when relevant: e.g., Draft, Active, or a semantic version.

Suggested Naming Pattern

A repeatable pattern helps searchability and governance. One recommended pattern is:

<Object> - <Trigger> - <Action> - <ExtraInfo>

Examples:

• Contact - Before Save - Set Preferred Language
• Opportunity - After Save - Create Renewal Task
• Case - Record-Triggered - Escalate to Manager - SLA15

Element-Level Naming

Name elements inside Flow (like Get Records, Assignment, Decision) using the same clarity:

• Get Primary Account instead of Get_1
• Assign: SetRenewalDate instead of Assignment2
• Decision: Is High Value Account? instead of Decision_3

Prefix element types optionally to make them immediately identifiable in the Flow canvas (e.g., G - Get Account, A - Set Flags, D - Check Status).

Include Metadata in Names

Embedding metadata like the trigger type and target object reduces ambiguity:

• Trigger type: Record-Triggered, Scheduled, or Screen.
• Action intent: Create, Update, Notify, Validate.
• Scope or conditions: e.g., SLA30, HighValue, AfterClose.

Versioning and Drafts

Flows update frequently. Capture version or status info to distinguish work-in-progress from production:

• Opportunity - After Save - Send Invoice - v1.2
• Lead - Screen - Qualification - Draft

Avoid storing transient developer notes in the name; instead use the Flow description field for implementation details, logic notes, or testing instructions.

Governance and Naming Policy

Document a short naming policy and enforce it during change reviews:

• Define required segments (object, trigger, action).
• Set maximum length guidance (e.g., 80 characters) to keep names readable in the UI.
• Agree on abbreviations and reserved prefixes (for managed packages or integrations).
• Use the Flow description to store owner, last modified intent, and Jira/Issue references.

Searchability Tips

Make names easy to find using Salesforce search and external documentation:

• Include consistent keywords (e.g., Notify, Validate, Assign).
• Tag Flows with category-like prefixes if your org supports it (e.g., INT- for internal, INTG- for integrations).
• Keep the most important terms at the beginning of the name.

Examples — Good vs. Bad

Compare choices:

• Good: Account - Before Save - Normalize Phone
• Bad: Flow_update1
• Good: Case - After Save - Notify Support - SLA72
• Bad: CaseFlow

Checklist Before Finalizing a Flow Name

• Does the name include the object and trigger type?
• Is the intended action clear?
• Is it consistent with existing naming patterns in the org?
• Is it short enough to be readable on the canvas and in lists?
• Is additional context better placed in the description?

Conclusion

Consistent naming conventions for Flows reduce risk, improve maintainability, and increase clarity for admins and developers. Create a simple, documented pattern (object — trigger — action — extra info), enforce it during reviews, and use the description field for deeper technical notes.