[Guide] Salesforce Architecture Planning: A Roadmap Template and Worked Example

Salesforce architecture planning connects a business outcome to the system decisions needed to deliver it. A useful roadmap records dependencies, accountable owners and acceptance evidence, then sequences work around unresolved risks. Start with what must improve for the business; choose components and delivery dates after the critical constraints are understood.

Download the Salesforce planning and debt toolkit. Use its Roadmap sheet alongside the illustrative example below. Replace the sample rows with your own decisions before using it for delivery planning. It is an editable planning aid, not an official Salesforce methodology or a delivery estimate.

What does Salesforce architecture planning need to decide?

Start with a decision the business actually needs to make. “Implement Salesforce capabilities” is too broad. “Give sales an accurate order status without asking finance to investigate each request” gives the plan a purpose and a boundary.

Describe the current problem, who experiences it and what evidence would show improvement. The business owner should define an acceptable result before the team selects a technical design. If nobody knows the current delay or error frequency, measuring it belongs in the plan.

Then examine the constraints that could change the design:

• Which system owns customer, order and payment facts?
• How fresh must the information be for the user’s decision?
• Who may see it, and who approves that access?
• What happens when a dependency is unavailable?
• Which volume assumptions need testing?

Salesforce’s architecture planning guidance recommends examining requirements, expected volumes and platform constraints before significant build investment. It also recommends recording important decisions and validating risky assumptions with prototypes.

Apply that guidance to your own boundary. A sales visibility requirement does not automatically justify redesigning the finance system.

What belongs in the roadmap template?

Keep one row per meaningful decision or deliverable. A task list with hundreds of implementation steps obscures the choices leadership needs to resolve.

Template field	What to record
ID	A stable reference other rows can depend on
Business outcome	The operational change this work supports
Decision or question	The choice that must be resolved
Evidence and status	What is known, assumed or still awaiting validation
Dependencies	IDs of decisions or deliverables required first
Accountable owner	The person responsible for getting a decision made
Next action	A concrete investigation, approval or delivery step
Acceptance evidence	What will demonstrate that this row is complete
Sequence and status	Its place in the plan and whether it is proposed, blocked, agreed or complete

Give a row one accountable owner even when several people contribute. “IT and the business” leaves nobody responsible for resolving disagreement.

Salesforce publishes capability, component, feature and system roadmap examples. Choose a view suited to the discussion. Executives may need the sequence of business capabilities; the delivery team needs the component dependencies behind it. Both views should refer to the same underlying decisions.

What does a worked Salesforce roadmap look like?

Consider an illustrative company using Salesforce for sales and an ERP for order fulfillment. Sales representatives ask finance for delivery updates. The company wants order visibility in Salesforce while the ERP continues to own fulfillment status.

This example describes planning logic. It is not a client case study, a recommended product combination or a promised schedule.

ID	Decision or deliverable	Depends on	Accountable owner	Acceptance evidence
R1	Agree the business outcome and acceptable information delay	None	Sales operations lead	Signed-off user scenarios and baseline measurement
R2	Define order identity and source of truth	R1	Data owner	Approved mapping with representative exceptions
R3	Agree access for each sales role	R1	Business access owner	Approved access matrix, including denied-access cases
R4	Test the integration approach and recovery behavior	R2, R3	Integration lead	Results for normal, duplicate, delayed and failed messages
R5	Deliver a limited pilot with support procedures	R4	Delivery lead	User acceptance, reconciliation results and support walkthrough
R6	Decide whether to extend the rollout	R5	Program sponsor	Pilot outcomes, unresolved risks and an explicit proceed or revise decision

R2 is more consequential than adding an order status field. If the systems do not agree which order a message describes, an attractive screen can display the wrong information confidently.

R4 tests assumptions before broad rollout. For example, a failed message may be retried by the sending system. The receiving design must define how duplicate delivery affects the resulting business state. Test that behavior instead of relying on an architecture diagram as evidence that recovery works.

R6 keeps rollout conditional. A pilot is useful when its result can change the plan. If rollout is already irrevocably committed, calling an earlier release a pilot does not reduce the risk.

How should you record architecture decisions?

Use a short architecture decision record, or ADR, for choices that materially affect cost, risk or future options. Salesforce’s ADR guidance covers context, the chosen option, alternatives and consequences, including reasons to revisit the decision.

For R2, an illustrative record might say:

Decision: The ERP remains the authority for fulfillment status. Salesforce displays a copy for the agreed sales use cases.
Reason: Sales needs visibility, while fulfillment changes remain part of the ERP process.
Alternative considered: Allow sales users to update fulfillment status from Salesforce. Rejected because this scope does not define authority or reconciliation for those changes.
Consequence: The design must communicate freshness and handle missing or delayed updates.
Revisit trigger: Sales receives responsibility for changing fulfillment instructions.

Link the record to R2 rather than copying its contents into every document. Record who agreed to it and when. Preserve superseded decisions so a future team can understand why the design changed.

How do you prioritize dependencies without inventing dates?

Separate discovery, decisions and delivery. An unknown with a large effect on scope deserves an investigation before a precise estimate.

For the example, agreeing acceptable information delay could change the integration approach. Resolve that question before committing to a delivery sequence based on an untested assumption about immediate updates.

Use “next,” “after R4” or an agreed planning window while dependencies remain open. Add dates when owners, capacity and required decisions support them. A date entered for presentation purposes quickly becomes a promise somebody plans around.

Technical debt can also block the sequence. Link such work to the debt scorecard and identify the capability it prevents. Avoid a separate cleanup backlog with no connection to delivery decisions.

When is a lighter plan enough?

A contained change with understood dependencies may need only a short design note and normal acceptance criteria. Do not create a review board for a label change.

Use a broader roadmap when work crosses systems, teams or business units, or when a wrong decision would be costly to reverse. If current behavior is uncertain, an architecture review can establish the evidence the plan needs.

Your internal architect can own this process. If nobody has the remit to resolve competing priorities, Salesforce strategy and architecture advisory can provide a defined decision-making role alongside your team.

What should you take away?

• Write the business outcome before selecting components.
• Give every material dependency an owner and acceptance evidence.
• Keep untested assumptions visible until evidence resolves them.
• Revisit the roadmap when a decision’s conditions change.

For the current-state assessment, read the architecture review guide. For work that delays future changes, see the technical debt overview.

What else do teams ask about Salesforce architecture planning?

What should a Salesforce architecture roadmap include?

Include business outcomes, architecture decisions, dependencies, accountable owners, the next action and acceptance evidence. Show which assumptions remain untested before committing to delivery dates.

How is architecture planning different from an architecture review?

An architecture review assesses the current system and its risks. Architecture planning uses that evidence, alongside business priorities and constraints, to decide what to change and in which order.

Does every Salesforce change need an architecture decision record?

No. Record decisions that cross system or team boundaries, create material cost or risk, or are expensive to reverse. Routine changes can use existing standards and normal delivery records.

Can an internal team build its own Salesforce roadmap?

Yes, if the team has the business context, technical judgment and authority to resolve dependencies. Outside help is useful when decisions span teams, evidence is disputed or nobody owns the overall design.