Start from the process, not the object model
The fastest way to build an unusable org is to begin with objects and fields. Start instead with the three or four revenue or service processes the business cannot afford to get wrong, walk them end to end with the people who run them, and only then decide what standard Salesforce functionality covers and what genuinely needs configuration.
This ordering matters because Salesforce is generous: almost anything can be built. The constraint is not capability but consequence. Every custom object, trigger and flow you add is a permanent maintenance obligation and a future upgrade risk, so the work of a consultant is as much about refusing requests as fulfilling them.
- Map the critical processes before touching the data model
- Prefer standard objects and declarative automation until they demonstrably fail
- Record every customization decision with the business reason behind it
Data ownership decides whether the org is trusted
Adoption collapses the first week a sales leader sees a pipeline number they do not believe. Before build starts, agree who owns each core record type, what the source of truth is for accounts and contacts, how duplicates are prevented rather than cleaned up, and which fields are required at each stage.
Integration design belongs in the same conversation. When Salesforce sits alongside ERP, billing and a data platform, decide deliberately which system writes and which reads — bidirectional sync chosen by default is how teams end up with two contradictory truths and no way to reconcile them.
Release engineering is not optional
Serious Salesforce delivery uses source control, scratch or developer orgs, automated deployment and a defined release cadence. Change sets moved by hand on a Friday are the reason organizations lose confidence in their own platform team.
The practical setup is unglamorous: metadata in Git, a pipeline that validates against a staging org, Apex test coverage treated as a quality signal rather than a compliance number, and a rollback plan that someone has actually rehearsed.
Plan the handover from day one
The measure of a consulting engagement is what the client can do six months after it ends. That means internal admins and developers pairing on real stories during the build, documentation written as the work happens, and a support model agreed before go-live rather than negotiated in a crisis.
At AX3 this is why engineers stay embedded through stabilization rather than leaving at launch. The last ten percent of a program — the part where people change how they work — is where the value either lands or evaporates.