Know what state your Salesforce org is actually in.
An independent review of a live org across six areas, with the findings written down, evidenced and sized. Run by engineers who support production Salesforce platforms every day, not by a checklist.
- Duration
- Two to three weeks
- Access required
- Read-only administrator, plus four to six interviews
- Ends with
- A written report and a live readout
When a review is overdue.
Salesforce orgs rarely fail outright. They degrade, quietly, until a release breaks something visible or an auditor asks a question nobody can answer.
One or more of these is usually true.
If several of them are true at once, the cost of finding out is far lower than the cost of the next surprise.
- Your org is three or more years old and has had several owners.
- The admin or partner who built it has left, and the reasoning left with them.
- A large programme is about to start on top of the platform.
- Release changes keep breaking things nobody expected them to touch.
- Users have started working around the system in spreadsheets.
- A board, auditor or new executive has asked for an independent view.
Nobody holds the whole picture.
Most established orgs have been worked on by several administrators, at least one partner and a few well-meaning power users. Each left something behind. The result is a platform where the cost of change rises every quarter and nobody can explain why.
Change costs more each time
A small request now takes days because no one is confident what else it touches. Estimates get padded to cover the unknown.
Automation fights itself
Flows, process builders and triggers accumulated over years now act on the same records in an order nobody chose deliberately.
Access has drifted
Permissions were granted for a project, a role or a person who has moved on. Nobody has reviewed who can see what since go-live.
Six areas, reviewed in full.
Every area is assessed with tooling and then verified by an engineer. Tooling finds what is there. Judgement decides whether it should be.
Configuration and data model
What the org actually contains, against what anyone believes it contains.
- Object and field inventory, including unused and duplicated fields
- Record types, page layouts and Lightning app structure
- Validation rules and the business logic hiding inside them
- Technical debt from superseded implementations
Data quality and integrity
Whether the records in the org can be trusted for reporting and for automation.
- Duplicate and orphaned record analysis
- Required field completeness on the objects that matter
- Ownership, sharing and record volume against limits
- Reporting accuracy against the source systems
Automation and code
Every path a record can travel, and the order it travels them in.
- Flows, workflow rules, process builders and triggers mapped together
- Overlapping or conflicting automation on the same object
- Apex quality, test coverage and governor limit exposure
- Managed package behaviour, including CPQ where present
Integrations
What crosses the boundary of the org, and what happens when it fails.
- Inbound and outbound interfaces with their owners
- Authentication method and credential handling
- Error handling, retry behaviour and failure visibility
- API consumption against your allocation
Security and access
Who can see and do what, and whether that still matches the organisation.
- Profiles, permission sets and permission set groups
- Sharing model, role hierarchy and manual sharing sprawl
- Administrator and modify-all access review
- Health Check score, session and password settings, event monitoring
Adoption and licensing
Whether the platform is being used, and whether you are paying for what you use.
- Login and feature usage by team
- Licence type allocation against actual usage
- Report and dashboard consumption
- Where users have left the platform for other tools
Six artefacts, all yours.
Everything produced during the engagement is handed over in full, in formats you can circulate internally without us in the room.
Assessment report
A written report covering all six areas. Each finding carries the evidence behind it, the risk it creates and the effort band to resolve it. Written for a technical reader, with an executive summary that stands on its own.
Prioritised remediation backlog
Every finding converted into a discrete, sized item, ordered by risk and by dependency. Written so any competent partner can execute it, not only us.
Automation and integration map
A single diagram of what fires on your core objects and what crosses the org boundary. In most engagements this is the artefact clients keep using long after the review.
Risk register
The issues that carry security, compliance or continuity exposure, separated from the improvement list so they can be escalated without the rest of the detail.
Live readout
A ninety minute session with your platform owners and, where useful, your executive sponsor. We present the findings, defend them, and answer the questions the document raises.
Ninety day plan
A sequenced plan for the first quarter of remediation, with the items that must be done before any new build starts marked clearly.
Three weeks, week by week.
A smaller org completes in two weeks. Findings are shared as they emerge, so nothing in the readout is new information to your platform owner.
- Week 1
Access, discovery and automated analysis
We take read-only access and run our analysis tooling across metadata, automation and permissions. In parallel we interview the platform owner, an administrator, two or three business users and, where one exists, the integration owner.
- Week 2
Deep review and verification
Manual review of everything the tooling flagged, plus the areas tooling cannot judge: whether the data model still matches the business, whether the automation order is deliberate, whether the sharing model reflects the current organisation. Findings are verified before they are written down.
- Week 3
Report, backlog and readout
We write the report, size the backlog and sequence the ninety day plan. You receive the document at least two working days before the readout so your team can read it properly and arrive with questions.
What this engagement is not.
The boundary is fixed so the duration holds. Anything below can be quoted separately once the review has told us what is worth doing.
- No changes are made in your org. This is a review, not a remediation.
- No data migration, cleansing or deduplication is performed.
- No code is rewritten or refactored during the engagement.
- It is not a penetration test. Platform security configuration is assessed, infrastructure is not attacked.
- We do not negotiate your Salesforce contract or licensing on your behalf.
- User training and change management are out of scope.
The ones we are asked most.
Do you need access to production?
Read-only administrator access to production gives the most accurate result, because sandboxes drift. Where policy prevents it, we work from a full copy sandbox plus a metadata export and note the reduced confidence in the report.
Will this disrupt our users?
No. Nothing is changed and no deployment occurs. The only demand on your people is four to six interviews of roughly forty five minutes each.
How large an org does this suit?
It works from around twenty users upward. Beyond roughly five hundred users, or where several managed packages are in play, we scope at the upper end of the duration.
We run CPQ and several managed packages. Is that covered?
Yes. Managed package behaviour, including CPQ product, pricing and approval configuration, is assessed as part of the automation and code area. We have run CPQ-centred estates in production for years.
Do we have to engage you for the remediation?
No. The backlog is deliberately written so another partner or your internal team can execute it. A reasonable number of clients take the report and do exactly that.
How is our data handled?
Under a mutual non-disclosure agreement, with least-privilege access requested for a fixed window and revoked in writing on completion. We extract metadata and aggregate usage data, not customer records.
Find out where the org actually stands.
Thirty minutes with an engineer is usually enough to tell whether a health check is the right next step, or whether you already know the answer.