If you have been asked to produce a Salesforce business requirements document for an implementation that is already showing signs of scope drift, start here. The configuration team will make decisions today — field names, stage labels, automation triggers — and every one of those decisions made without documented requirements is a bet they are placing on your behalf. A Salesforce BRD is not paperwork. It is the single artefact that stops an administrator from building the system they imagine your stakeholders need rather than the one they actually need.
I have been on more than a handful of Salesforce implementations where configuration started before requirements were properly captured. The pattern is always the same. The administrator is keen to show progress, the project sponsor wants something on screen, and I am still trying to get diary time with the sales team. Three months later, everyone is in a meeting arguing about why the pipeline stages do not match the actual sales process and whether it is faster to reconfigure or just live with it. Getting the BRD written and signed off before configuration begins is not a process preference. It is the only thing that prevents that meeting from happening.
What a Salesforce BRD Needs to Cover
A general BRD template will get you part of the way there, but Salesforce implementations have specific characteristics that need deliberate treatment. The platform is highly configurable out of the box, which means stakeholders frequently conflate what they want with what the system already does. Your document needs to draw a clear line between current-state problems, future-state requirements, and Salesforce-specific configuration decisions.
- Business context and objectives: Why is the organisation implementing or reconfiguring Salesforce? What outcomes are expected within a defined timeframe? Vague answers here will cause scope creep from week two onwards.
- Current-state process documentation: Which processes are moving into Salesforce and what do they look like today? Do not skip this because stakeholders assume it is obvious. It never is.
- Stakeholder requirements by role: Sales reps, sales managers, marketing, customer service, and finance all have different needs from the same system. Capture them separately before you attempt to reconcile them.
- Object and field requirements: Which standard Salesforce objects will be used? Which need customisation? What custom objects are required? What fields need to be created, renamed, or made mandatory?
- Data requirements: What data is being migrated from legacy systems? What is the source, what is the quality, and who owns the data cleansing effort?
- Integration requirements: Does Salesforce need to connect to a finance system, an ERP, or a marketing automation platform? Each integration needs its own requirements covering data flow direction, frequency, and error handling.
- Security and access requirements: Salesforce has a layered security model involving profiles, permission sets, roles, and sharing rules. You need requirements that an administrator can translate directly into that model.
- Reporting and dashboard requirements: What does each stakeholder group need to see and how often? Salesforce reporting is powerful but only if someone has specified what questions the reports need to answer.
- Non-functional requirements: Performance expectations, data retention policies, and compliance requirements all need to be documented. These are easy to overlook on a CRM project but they matter, particularly in regulated sectors.
How to Structure the Document
I typically structure a Salesforce BRD in the following order, though you should adapt it to whatever governance framework the organisation uses. The assumptions section deserves particular attention. It is where you record things like “this requirement assumes the organisation has Salesforce Sales Cloud Enterprise edition” or “this requirement assumes the legacy CRM data can be exported in CSV format.” Assumptions that are not documented become disputes later.
- Executive summary and business objectives
- Scope: what is in and what is explicitly out
- Stakeholder map and RACI
- Current-state process overview
- Future-state requirements by functional area
- Salesforce object and field requirements
- Data migration requirements
- Integration requirements
- Security and access requirements
- Reporting and dashboard requirements
- Non-functional requirements
- Assumptions, constraints, and dependencies
- Sign-off and review history
A Worked Example: When the Sales Director Pushed Back
On a mid-sized Salesforce Sales Cloud implementation I was involved in for a professional services organisation, I ran initial workshops with the sales team and documented what I believed were solid requirements for the opportunity management process. We had defined stages, probability percentages, required fields at each stage, and a clear owner for each record type.
When I took the draft BRD to the sales director for sign-off, she flatly refused to approve the stage called “Proposal Submitted.” Her position was that her team never used that language internally, and that forcing reps to move an opportunity to that stage would create more admin work, not less. She wanted the stage renamed and the mandatory fields at that point reduced from four to one.
This was not a minor edit. Two other requirements depended on that stage name: a dashboard metric counting proposals in flight, and an automated email trigger to the commercial team. I had to go back to the commercial manager and the marketing operations lead to get agreement on revised requirements before I could update the BRD. It added four days to the elicitation phase.
The friction was useful. It surfaced a genuine disagreement about what “Proposal Submitted” even meant in that business. The sales director’s version and the commercial manager’s version were different activities. If I had not taken the BRD through formal sign-off before configuration started, the administrator would have picked one interpretation and neither team would have been happy with the result. This is exactly why your Salesforce BRD needs explicit approval at the process level before it gets anywhere near configuration work.
The Two Requirement Types Most BRDs Miss
Automation Requirements
Salesforce supports workflow rules, flow, and approval processes. Stakeholders often describe these as “the system should automatically do X when Y happens” without realising they are describing automation logic that needs precise specification. Every automation requirement in your BRD should state the trigger, the condition, the action, and the exception handling. Vague automation requirements are where Salesforce projects accumulate the most technical debt.
Permission and Visibility Requirements
I have seen BRDs that describe functional requirements in detail but say almost nothing about who can see or edit each piece of data. On a Salesforce project this is a critical gap. The security model needs to be specified in requirements, not left for the administrator to decide. At minimum, document which profiles need access to which objects, which fields should be read-only for certain roles, and whether any records need to be restricted below the standard role hierarchy. The requirements elicitation checklist on this site is a useful starting point for making sure you have not missed a category before you close the elicitation phase.
BRD vs Functional Specification: Where to Draw the Line
One of the most common questions I get from early and mid-career BAs is how detailed a Salesforce BRD should be. The honest answer is: detailed enough that an administrator who has never spoken to your stakeholders could configure the system correctly from the document alone. That is a high bar, and you will not always reach it on the first draft, but it is the right target.
If your requirements say “the system should capture customer contact details,” that tells an administrator almost nothing. If they say “the Contact object requires First Name, Last Name, Email, Mobile, Account, and Job Title as mandatory fields, with a custom field for Preferred Contact Method using a picklist of values: Email, Phone, Post,” that is a configurable requirement.
The distinction between business requirements and functional requirements matters here. Your BRD should capture what the business needs to achieve and why. The functional detail of how Salesforce will deliver it can sit in a separate functional specification or be elaborated in user stories if you are working in an agile delivery model. The article on BRD vs FRD covers that boundary in more detail if you are unsure where to draw the line for your specific project.
| Requirement Type | Belongs in the BRD | Belongs in the Functional Spec |
|---|---|---|
| Business objective | Yes | No |
| Current-state process | Yes | No |
| Object and field list | Yes (what and why) | Yes (how configured) |
| Automation trigger and condition | Yes (business rule) | Yes (technical logic) |
| Picklist values | Yes | Sometimes |
| Profile and permission set names | No | Yes |
| Page layout configuration | No | Yes |
| Integration field mapping | No | Yes |
Before You Write a Single Section
Before you open a document template, spend time understanding the organisation’s existing Salesforce environment if one exists, their licence type, and what third-party apps are already installed. I have seen BRDs written in complete isolation from the technical reality, only for the project to discover mid-implementation that the required feature is not available on their licence tier, or that an existing app already does half of what was specified. That upfront research shapes every requirement you write. It is the difference between a BRD that drives useful configuration work and one that generates a long list of change requests before go-live. If you are not sure how to structure that pre-documentation research phase, the guide on how to document your findings at the start of a project will give you a practical starting framework.
A Salesforce BRD written before configuration begins, signed off by the right people, and specific enough to be acted on without a phone call, is one of the highest-value artefacts you will produce on any CRM project. The time you invest getting it right before the administrator touches the sandbox is returned tenfold in avoided rework, cleaner data migration, and stakeholders who trust the system they actually receive.
Frequently asked questions
What should a Salesforce business requirements document include?
A Salesforce BRD should cover business objectives, current and future state processes, object and field requirements, data migration scope, integration points, security and access rules, reporting needs, and non-functional requirements. Automation logic and permission structures are two areas most commonly missed. Each section should be specific enough that a Salesforce administrator could act on it without needing to ask clarifying questions.
Do you need a BRD for a Salesforce implementation?
Yes. Without documented requirements, Salesforce administrators make configuration decisions based on assumptions, and those assumptions get baked directly into the system. A BRD gives the project a shared baseline that prevents rework, scope disputes, and misaligned configuration. Even in agile delivery, a high-level BRD helps frame the user story backlog.
How detailed should a Salesforce requirements document be?
Detailed enough that an administrator unfamiliar with the stakeholders could configure the system correctly from the document alone. Field-level requirements, picklist values, mandatory field rules, automation triggers, and sharing logic all need to be specified rather than implied. If a requirement could be interpreted in more than one way, it needs more detail.
What is the difference between a Salesforce BRD and a Salesforce functional specification?
A BRD captures what the business needs to achieve and why, including process requirements, object and field needs, and automation rules expressed as business logic. A functional specification describes how Salesforce will deliver those requirements, including page layouts, profile names, and integration field mappings. On smaller projects these may be combined, but on larger implementations they are separate documents with different audiences and sign-off processes.
Who should sign off a Salesforce business requirements document?
Key stakeholders from each affected business area should review and sign off the BRD before configuration begins. This typically includes the sales or service lead, a data or IT representative, and the project sponsor. Missing sign-offs are a leading cause of mid-project rework because unresolved disagreements surface only after configuration is underway.
Try Ash, Your Virtual BA
If you are currently working through a Salesforce BRD and want to pressure-test your structure, check for sections you may have missed, or get help phrasing a specific requirement clearly enough for an administrator to act on, Ash is the logical next step. Ash is built on 25 years of BA practice and can guide you through the BRD section by section, flag gaps in your automation or permissions requirements, and help you produce a document that will hold up in stakeholder review. Try Ash Virtual BA and get your Salesforce BRD to a standard that drives clean configuration from day one.
Further reading
- Successfully Documenting Requirements for a Project | IIBA® Business Analysis Blog
- Business Requirements at the Core: How to Uncover, Model, and Align Analysis with Real Business Needs | IIBA
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.