Salesforce Solution Design: [Programme or org name]

Solution design document for a Salesforce implementation: org strategy, licences and personas, data model and large data volumes, sharing and visibility, identity, automation and transaction design, integration (APIs, Platform Events, Change Data Capture, Pub/Sub API), Agentforce agents, environments and DevOps, data migration, performance against governor limits, and a review against the five pillars of the Salesforce Well-Architected framework (Trust, Reliability, Operational Excellence, Resource and Cost Optimization, Fairness) with its Agentic Enterprise lens, as published on architect.salesforce.com in September 2026. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Scope, drivers and principles
2. Org strategy
3. Licences and personas
4. Data model and large data volumes
5. Sharing and visibility
6. Identity and access
7. Automation and transaction design
8. Integration
9. Agentforce and AI
10. Environments and DevOps
11. Data migration
12. Performance and limits
13. Security, privacy and compliance
14. Well-Architected review
15. Testing and release readiness
16. Decisions, risks and traceability
17. Glossary and references

1. Scope, drivers and principles

1.1 Business drivers and outcomes

1.2 Scope

The process-level scope and the standard-versus-custom decision for each requirement come from the Fit-gap analysis (architecture/fit-gap-analysis). Reference its requirement IDs in section 16 rather than repeating them.

1.3 Design principles

2. Org strategy

2.1 Single org or multiple orgs

Assess the options against the criteria below and record the choice in the decision log. A single org is the default when business units share customers, products or service processes; separate orgs are justified by hard isolation needs, incompatible release cadences or regulatory separation.

Example calculation: single org = 0.30 x 5 + 0.20 x 3 + 0.15 x 2 + 0.20 x 5 + 0.15 x 4 = 1.50 + 0.60 + 0.30 + 1.00 + 0.60 = 4.00. Hub and spoke = 0.30 x 2 + 0.20 x 5 + 0.15 x 5 + 0.20 x 2 + 0.15 x 2 = 0.60 + 1.00 + 0.75 + 0.40 + 0.30 = 3.05. Replace the weights and scores with your own, agree the weights before scoring, and record who scored.

2.2 Infrastructure and residency

2.3 Release cadence

Salesforce ships three major releases a year (Spring, Summer and Winter). Winter '27 became generally available on 12 October 2026 per the Salesforce release announcement. Plan a regression cycle in a preview sandbox for every release, and keep a register of release updates (enforced changes) with the date each one is enforced.

3. Licences and personas

Check each feature against the licence it needs. Record entitlements that drive cost by consumption (API calls, Data 360 credits, agent conversations or actions, storage) in section 12.3.

4. Data model and large data volumes

4.1 Entity relationship overview

The diagram shows the core objects for release 1 and their cardinality; custom objects end in __c.

4.2 Object inventory

Treat an object as a large data volume object when it reaches millions of records or when queries, sharing recalculation or reports on it already slow down in a full copy sandbox. For each such object record: the selective filters that every query uses, the indexed fields (standard indexes, custom indexes requested through Support, external ID fields), whether a skinny table is needed, and the archive target (Big Objects, an external store read through Salesforce Connect, or the data platform).

4.3 Data skew register

Salesforce guidance commonly treats around 10,000 child records under one parent, or owned by one user, as the point where skew begins to cause locking and sharing recalculation problems. Check the current large data volume guidance and test with production-scale volumes in a full copy sandbox before accepting any design that concentrates records.

5. Sharing and visibility

5.1 Org-wide defaults

5.2 Access layers

Describe each layer that opens access above the defaults, in this order: role hierarchy, sharing rules (owner-based and criteria-based), teams (account, opportunity, case), territory management, manual sharing, restriction rules (which narrow access), and Apex managed sharing. For external users, describe sharing sets, share groups and the external role hierarchy. Keep the role hierarchy shallow and modelled on data access, not on the organisation chart.

5.3 Field and object permissions

Grant object and field permissions only through permission sets combined into permission set groups; keep profiles minimal. List sensitive fields (personal data, pricing, health or financial data) and the permission set that grants each one. Plan for sharing recalculation time when changing defaults or rules on large objects and schedule it in a maintenance window.

6. Identity and access

Use one integration user per connected system so that audit trails and permission scopes stay separable. Customer and partner identity design belongs in CIAM solution design (security/ciam-solution-design) when it is shared with other channels. Note that Salesforce has removed some legacy OAuth flows for its own CLI connected app (the Trust pillar guidance records that the device flow was blocked from 28 August 2025); review every connected app for flows that Salesforce is retiring.

7. Automation and transaction design

7.1 Tool selection

Salesforce publishes decision guides for automation tool choice on architect.salesforce.com; record the guide version you followed.

7.2 Automation inventory and order

7.3 Governor limits to design against

The per-transaction Apex limits below are the ones designs most often hit. Values were checked in October 2026 against the Apex Developer Guide and the Reliability pillar; confirm them for your release.

Set a design headroom target, for example keep normal peak usage below 70 % of each limit so that unusual records and future logic still fit. Count limits for the whole transaction, including every flow, trigger, managed package and process that the save fires.

8. Integration

8.1 Integration patterns

Platform events and change data capture events are retained for 72 hours; a subscriber can replay from a stored replay ID within that window, but Salesforce does not guarantee events older than 72 hours. Design a reconciliation job for any outage longer than the window.

8.2 Interface catalogue

Specify each interface in detail in Integration design (architecture/integration-design); align with the enterprise rules in Integration strategy (architecture/integration-strategy) and, when an event backbone exists, Event-driven architecture design (architecture/event-driven-architecture-design).

9. Agentforce and AI

For each agent record the agent user and its permission sets, the data masking and retention settings, the test set used for evaluation, and the monitoring in place after go-live. The Winter '27 release notes state that Agentforce is enabled by default in orgs that have Agentforce access through their edition or licences, with rolling enablement of existing orgs from September 2026, so confirm the org settings and permission boundaries before the release reaches production. Detailed agent behaviour belongs in AI agent specification (ai-data/ai-agent-spec), threats in Agentic threat model (ai-data/agentic-threat-model).

10. Environments and DevOps

10.1 Environment plan

10.2 Source control and pipeline

Scratch orgs are created from a Dev Hub; when the Dev Hub runs on Hyperforce, its scratch orgs are also created on Hyperforce. Check the scratch org allocation for your edition before planning one org per developer per feature.

11. Data migration

Use external ID fields on every migrated object so loads are repeatable upserts. Defer sharing calculation for large loads where the org supports it, and plan the recalculation window. Full scope, mock loads and fallback are in Data migration strategy (architecture/data-migration-strategy); the reconciliation evidence goes in Data migration reconciliation (project/data-migration-reconciliation).

12. Performance and limits

12.1 Org-level limits and consumption

12.2 Performance targets

12.3 Consumption-based cost drivers

List every item billed by consumption: Data 360 credits, Agentforce conversations or actions, extra API capacity, additional storage, sandbox add-ons and event delivery add-ons. For each, record the unit, the forecast, the alert threshold and the owner who approves increases.

13. Security, privacy and compliance

Record privacy assessments in DPIA (compliance/dpia) and treat managed packages as part of your trust boundary: review what data each package can read and send out.

14. Well-Architected review

The Salesforce Well-Architected framework, as published in September 2026, has five pillars and an Agentic Enterprise lens that adds agent-specific considerations to each pillar. An earlier edition of the framework was organised as Trusted, Easy and Adaptable; map any older review findings to the new pillars rather than keeping two structures.

15. Testing and release readiness

Go-live readiness is judged in Go-live readiness review (project/go-live-readiness-review), cutover steps in Cutover plan (project/cutover-plan) and the stabilisation period in Hypercare plan (ops/hypercare-plan).

16. Decisions, risks and traceability

16.1 Decision log

16.2 Risks

16.3 Traceability matrix

17. Glossary and references

17.1 Glossary

17.2 References

Standard and licence note

Structure aligned with the Salesforce Well-Architected framework (five pillars: Trust, Reliability, Operational Excellence, Resource and Cost Optimization, Fairness, with the Agentic Enterprise lens) as published on architect.salesforce.com in September 2026, and with Salesforce developer documentation for governor limits, event durability and DevOps. Only pillar names, topic names, product names and checked limit values are used; all explanations, criteria and examples are original text written for this collection. Check the current Salesforce documentation for your release before relying on any limit or feature. Salesforce, Agentforce, Hyperforce and related product names are trademarks of their owners; this template is not affiliated with or endorsed by them. Template licence: MIT.