A Salesforce implementation is rarely a one-time project. It is the start of a platform that grows with your organization, sometimes for years. The choices you make in the first months determine how flexible, manageable and scalable that platform will be later. Some of those choices are easy to reverse. Others are in it forever.
In this article we discuss seven technical decisions that we see in practice make the difference between an implementation that continues to work and one that is rebuilt after two years.
1. Ownership and governance: who is in charge of the platform?
Technically the least glamorous choice, but in practice the most impactful. Without clear ownership, Salesforce environments quickly grow into a proliferation of fields, flows, and custom objects that no one dares to touch.
Determine in advance who:
- Approves and documents new configurations
- Determines which processes belong in Salesforce and which do not
- The internal Salesforce administrator, or whichever external party fulfills that role
- Makes release decisions in case of changes in production
A governance model does not have to be heavy. A simple change log, a permanent administrator and a short decision line are often sufficient for SMEs.
2. Data model: are you building for now or for later?
The Salesforce data model is the backbone of your implementation. Mistakes in this are expensive: renaming fields sounds simple, but if twenty flows, reports and integrations depend on it, it becomes a project in itself.
Common mistakes:
- Too many custom fields on standard objects without a clear purpose
- Relationships that later prove difficult to adjust (e.g. incorrect use of Master-Detail vs. Lookup)
- No naming convention for API names, making the data model unreadable after a year
Spend time in the design phase thinking through your object structure. That will yield much more later than a quick start.
3. Declarative versus custom: when to write Apex?
Salesforce offers powerful no-code and low-code capabilities through Flow, validation rules and formulas. The rule of thumb is: use declarative unless there is no other option. Apex code requires developers, test classes, and a deployment pipeline. Don’t flow.
Choose Apex when:
- Complex bulk processing is required that hits Flow limits
- Asynchronous processes are required (Queueable, Batch)
- External API calls in complex patterns must be handled
Avoid the temptation to build everything in Apex just because a developer is available. A well-built Flow is easier to manage by an admin and cheaper to maintain.
4. Integration patterns: real-time or asynchronous?
Almost every Salesforce environment integrates with other systems: an ERP, a marketing platform, an external portal. The choice between real-time and asynchronous integration has a major impact on reliability, complexity and costs.
Realtime (via REST API or Platform Events) works well when immediate feedback is needed, but requires robust error handling. Asynchronous integration via a middleware layer (MuleSoft, Make, Azure Logic Apps) is more flexible and resilient to failures.
Always record integrations in an integration map: which system is the master for which data, in which direction does data flow, and what happens in the event of a failure?
5. Identity and authorizations: least privilege from day one
One of the most underestimated parts of an implementation is the authorization structure. Organizations often start with broad profiles (“everyone can see everything”) and try to limit them later. That’s a world upside down.
Build your permission model in advance based on the principle of least privilege: users only get access to what they need. Use Permission Sets for additional permissions, and avoid customizing default profiles. That makes future changes and audits a lot easier.
6. Testing and deployment: no production sandbox
Too many Salesforce environments are built directly in production. That works until it doesn’t work anymore: an error in a flow, an incorrect validation rule or a failed update can bring the entire department down.
Set up a simple deployment pipeline:
- Developer sandbox for building and testing
- Partial/Full copy sandbox for UAT with real data
- Change sets of SF CLI for controlled deployments to production
This sounds heavier than it is. Even a small organization can benefit from a simple sandbox strategy.
7. Monitoring and management: knowing what’s going on
If a flow fails in production, you want to know before a user reports it. Set up monitoring from the beginning via:
- Flow and Apex error messages via email notifications or a remote administrator account
- Setup Audit Trail for tracking configuration changes
- Event Monitoring (at Enterprise or Unlimited) for deeper usage and security logging
Also document which processes are critical, so that in the event of an incident it is immediately clear what has priority.
Conclusion
A good Salesforce implementation is more than a working configuration on the delivery date. It is a platform that will still be manageable, expandable and understandable in three years. This requires well-considered choices at the beginning, not perfection, but direction.
Are you at the beginning of an implementation or are you reaching the limits of your current environment? We are happy to take a look with you. Contact us for a no-obligation consultation.