Architecture decisions in Salesforce are often made under time pressure, with incomplete information, by people who may not be in the same role when the consequences manifest. A systematic approach to decision-making — one that is explicit about context, alternatives and trade-offs — produces better outcomes than intuition alone.
The decision-making principles
Reversibility matters more than optimality. In a rapidly evolving platform like Salesforce, the best architecture is often not the theoretically optimal one but the one that is easiest to change when requirements change. Favour flexible patterns over clever ones.
Constraints are inputs, not obstacles. Governor limits, object model constraints and platform behaviours are information about how Salesforce is designed to work. When a design fights the platform, the design is probably wrong.
Document the decision, not just the outcome. Future team members will see what was built. They will not see why unless you document it. Architecture Decision Records (ADRs) create institutional memory.
The build vs configure framework
For every new requirement, ask three questions in order.
First: can this be met by a standard Salesforce feature without any customisation? Standard objects, standard fields, standard automation, standard reports. This is always the first choice.
Second: can this be met declaratively with configuration? Custom objects, custom fields, Flow, validation rules, formula fields. Declarative solutions are maintainable by a wider team and do not require Apex test coverage.
Third: does this require Apex or other programmatic solutions? Choose code only when declarative tools genuinely cannot meet the requirement, or when the declarative solution is so complex that it would be harder to maintain than equivalent code.
Data model design principles
The data model is the hardest thing to change in a Salesforce org. Every other layer — automation, UI, integration — depends on the data model. Errors in the data model compound over time as every feature built on a flawed foundation inherits the flaw.
Object design questions
Before creating a new custom object, ask: does this data belong to an existing object as a field? Could this be a child of an existing object? Is this a new entity in the domain, or a specialisation of an existing one?
Relationship design questions
Before creating a new relationship: what is the cardinality? (One-to-one, one-to-many, many-to-many?) What is the cascade behaviour? (Should deleting the parent delete the children?) Is the child record meaningful without the parent? (Master-detail if not; lookup if yes.)
The External ID strategy
Every custom object that will participate in data loading or integration should have an External ID field from day one. Retrofitting External IDs onto objects with millions of existing records is painful. Adding them at design time costs nothing.
Summer ‘26 architectural considerations
Agentforce changes the automation calculus. For processes that involve natural language understanding, ambiguous inputs or adaptive decision-making, Agentforce agents are now a genuine architectural option. Evaluate Agentforce alongside Flow and Apex for new process automation requirements.
Flow Orchestration is now viable at scale. The removal of usage-based limits makes Flow Orchestration a practical choice for complex multi-step processes in Enterprise and above editions. Re-evaluate any decision previously made to use Queueable Apex chains for process orchestration.
Security defaults changed in API v67.0. Any architecture that relies on Apex’s old without-sharing default behaviour must be reviewed before upgrading to v67.0. Build explicit sharing declarations into your coding standards.
The governance model
Good Salesforce architecture is maintained, not just designed. Establish:
A naming convention standard that is documented and enforced. Inconsistent naming is the first symptom of governance breakdown.
An Architecture Review Board that reviews significant changes before development begins — not after deployment.
A technical debt register that makes accumulated shortcuts visible and manageable.
Regular architecture health checks — at least annually — that assess whether the current architecture still serves the organisation’s needs.
Test your knowledge — Architecture
10 questions · Basic to Advanced