Eighty system administrators, and nobody had counted

The client ran a Salesforce org that had been in production for years and grown by accretion: successive projects, several partners, no single owner of the architecture. It worked, mostly. Nobody could say whether it was safe.

That is the ordinary situation, and it is the hard one. There was no incident to investigate and no auditor at the door. The question was the harder version: if someone did look, what would they find? An internal team cannot answer that about itself, because the things that accumulate quietly are exactly the things nobody thinks to check.

We were asked for an independent read across four areas: security and access, automation and business logic, code quality, and the development and deployment process.

We ran the Salesforce Health Check first, because it is free, it takes minutes, and it establishes whether the conversation is about tuning or about triage. It came back at 48% of the standard baseline (the band Salesforce labels “Very Poor”) with thirteen high-risk settings and roughly twenty critical ones requiring immediate configuration.

Then we queried the org directly rather than trusting the configuration screens. Who actually holds the System Administrator profile. Who has View All and Modify All. Which admin accounts are still active but have not logged in for thirty days. Which objects have their default external access left open. The SOQL we used is in the appendix of the report the client keeps, so they can re-run every finding themselves.

For the code we read a defined subset of a codebase of over two hundred Apex classes and triggers, looking specifically for the failure modes that matter: DML without Field-Level and Object-Level Security enforcement, dynamic SOQL built from unsanitised input, queries inside loops, the global access modifier, and silent exception handling.

For automation we counted what was actually running: over two hundred active record-triggered flows executing in the same context as the triggers, plus ninety-three Flows, twenty Process Builder flows, a hundred and six Workflow Rules and ninety-four Lookup Rollup Summaries with no central documentation of what any of it did.

Every finding was scored against five impact areas (business, operational efficiency, customer and employee experience, performance and scalability, and security and compliance) so the client could rank remediation by consequence rather than by how loud the problem sounded.

The client received a written assessment naming what was wrong, what it put at risk, and what to do about it, in priority order. It is theirs. It could be handed to a new partner, an internal team, or an auditor without us in the room.

The access findings were the ones that moved first, because they are the cheapest to fix and the most expensive to leave: more than eighty users on the full administrator profile, over a hundred and ten with View All, fifteen dormant admin accounts still live, and no controls on data export.

The report also states plainly what it did not cover: org structure and governance, the data model, integrations, performance, backup and disaster recovery, and user experience. An assessment that claims to have looked at everything in two weeks has not looked properly at anything.

We are not publishing the client’s name. Security findings are not a marketing asset, and a firm that would publish yours is not a firm you should let near your org.