A Salesforce audit method for separation

A shared enterprise platform can contain dependencies that are easy to overlook during separation. The useful output is a scoped evidence register and a set of decisions, rather than a claim to have discovered everything.

Agree the boundary first

Establish the authorised scope, business ownership and access needed for the review. Prefer read-only collection and an appropriate test environment where available. Record limitations and the collection date. Protect exports as business information.

Build a staged inventory

Review metadata, configuration and integration dependencies in stages that can be retried. Relate each output to its source and version. A failed collection step must remain visible; it cannot become an empty result that looks like a pass.

Examine ownership and access separately

Business ownership, sharing configuration and effective access are related questions, but they are not interchangeable. An inventory signal should lead to a targeted investigation with the appropriate platform and business owners.

Write findings people can act on

Each finding needs the observed evidence, its limits, a broad risk description and an accountable owner. A remediation register should separate proposed changes, accepted decisions and verified outcomes.

An illustrative example might be an integration whose business owner needs confirmation. That is a question to resolve, not evidence of a live vulnerability. This page describes a method and contains no client findings, counts, queries or audit outputs.

Verify the transition

Before changing a dependency, agree how readiness and service continuity will be checked. Retain the evidence needed by the programme in an appropriately restricted location. A completed inventory alone does not establish separation readiness.