Salesforce projects often go wrong when teams start configuring the requested future before they understand the current process. A stakeholder asks for a new approval flow, an administrator opens Flow Builder, and only later does the team discover that half the approvals happen by email, one region uses a different threshold, Finance owns a hidden spreadsheet, and the \u201csame\u201d process means different things to Sales and Operations.<\/p>\n
For the Salesforce Business Analyst<\/a>, process mapping is a way to make that hidden work visible. The current-state map shows how work actually happens today. The future-state map shows how the organization intends it to work after change. The gap between them becomes a structured source of requirements rather than a collection of assumptions.<\/p>\n A useful map starts with scope. Name the triggering event, the intended end state, the customer or business outcome, and the teams that participate. \u201cLead management\u201d is too broad unless the project truly spans everything from acquisition through conversion. \u201cRoute an inbound enterprise lead from capture to accepted ownership\u201d is much easier to map and validate.<\/p>\n Identify what is explicitly out of scope. If pricing, contracting, or fulfillment begins after the mapped process ends, state that boundary. This prevents stakeholders from arguing about missing steps that belong to another process and helps the analyst know when a discovered issue should become a dependency rather than an expansion of scope.<\/p>\n Choose a level of detail appropriate to the audience. Executives may need a capability-level map with major stages. Process owners need handoffs, decisions, exceptions, and controls. Delivery teams may need enough detail to derive system requirements. One map does not have to serve every audience.<\/p>\n The documented procedure and the real process can differ. Interview people who perform the work, observe representative cases, review reports and queues, and inspect where data is entered outside Salesforce. Current-state mapping should capture actual behavior, including workarounds that people may consider temporary but have used for years.<\/p>\n Record who performs each step, what information they need, which system they use, what decision moves the work forward, and what happens when normal conditions fail. Pay special attention to handoffs because delays and data loss often occur when ownership changes between teams or systems.<\/p>\n Do not clean up the process while mapping it. If the analyst immediately redraws the \u201cbetter\u201d version, the team loses evidence about why the current process behaves as it does. First understand the present state accurately; improvement comes next.<\/p>\n A process map is more useful when it shows friction rather than only the happy path. Mark waiting periods, approval queues, duplicate entry, manual reconciliations, spreadsheet steps, email-based decisions, repeated data corrections, and places where users switch systems.<\/p>\n Ask what control each awkward step is trying to provide. A manual manager review may exist because a previous automation created financial risk. A spreadsheet may compensate for missing fields or provide a cross-system view that users cannot get in Salesforce. Removing the visible workaround without understanding the need can make the future state worse.<\/p>\n Measure where possible. Cycle time, queue age, rework rate, error volume, abandonment, and number of handoffs make the current state more objective. These measures also create a baseline for evaluating whether the future process actually improves performance.<\/p>\n The future-state map should describe how the business wants work to flow after the project, without prematurely binding every step to a Salesforce feature. Clarify which decisions should be automated, which require human judgment, which data should be authoritative, and which controls cannot be removed.<\/p>\n For example, the future state may say that discount requests above a risk threshold require approval from a designated role and must preserve an audit trail. That is a process requirement. Whether the implementation uses Salesforce approval functionality, Flow, Apex, or another mechanism comes later when the delivery team evaluates solution constraints.<\/p>\n Separate policy changes from system changes. If the future process works only because the organization changes approval authority, staffing, or data ownership, those decisions require business sponsorship. Salesforce cannot configure away an unresolved governance question.<\/p>\n Compare the maps step by step. Some current steps disappear because they are waste. Some remain but change owner. Some become automated. New controls may be introduced. Data may move to a different system of record. Each difference should produce a question, requirement, decision, dependency, or change-management action.<\/p>\n Classify gaps so they can be managed. A process gap describes changed workflow. A data gap identifies missing, duplicated, or unreliable information. A capability gap means the organization lacks a function needed by the future state. A policy gap requires a business decision. A security gap concerns access or segregation of duties. An integration gap requires information to cross system boundaries.<\/p>\n Not every gap belongs in Salesforce. A training issue, vendor contract, data-governance decision, or upstream master-data defect may need a different owner. The process map helps expose those dependencies before the configuration team is blamed for them.<\/p>\nDefine the process boundary before drawing boxes<\/h2>\n
Map the current state from evidence, not policy<\/h2>\n
Expose controls, delays, rework, and unofficial systems<\/h2>\n
Design the future state around outcomes and policy<\/h2>\n
Turn current-to-future differences into a gap analysis<\/h2>\n
Derive requirements without losing traceability<\/h2>\n