Salesforce org handover

Inherit a Salesforce org nobody documented — and know what you’re taking over.

A new client, a managed-services contract, a vendor who just left: the org is yours now, and the documentation is whatever the last team remembered to write. aprity reads the org read-only and gives you a map of what exists and how it behaves — objects, automations, business rules and integrations, in business language — in days of review rather than weeks of archaeology.

Start free trial Book a demo

Read-only access Metadata purged after each scan EU & US data residency

What it means

What is a Salesforce org handover?

A Salesforce org handover is the moment responsibility for an org moves from one team to another — a system integrator or consulting firm starting with a new client, a managed-services team onboarding a run contract, or an internal team taking back an org after a vendor leaves. The new owners have to support, fix and change an org they did not build. The first job is always the same: work out what the org contains and what it does, before touching anything. aprity does that reading for you, from the metadata, and keeps the result current with every scan.

Why inherited orgs hurt

You own it before you understand it.

Nobody wrote it down

What documentation exists describes the org as it was designed, not as it was built — and certainly not after years of fixes. The people who knew are gone or busy elsewhere.

Behaviour is spread everywhere

What happens when a record is saved is split across flows, triggers, Apex, validation rules and workflow. Reading it component by component is slow, and the order in which it runs is invisible.

Every change is a gamble

Without a map of dependencies, the first ticket on a new contract can break a report, an integration or a process nobody mentioned during the handover.

What the map contains

What exists, how it behaves, and what depends on what.

Dependencies and impact are computed deterministically from the metadata; the AI explains the result in business language. Nothing is guessed from naming conventions.

Objects and fields

Every object and field explained in business language, with a data dictionary built from the metadata.

Automations and execution order

The automations on each object and the order they run in for each save event, shown as an execution graph.

Business rules, with their source

Each business rule linked back to the component it was read from, so the team can check it rather than trust it.

Integrations in and out

Inbound and outbound integrations mapped from the Apex code's actual call-sites, not from declared metadata alone.

Impact before you touch

Pick a field, object or Apex class and see what depends on it downstream before you change it.

What changed since last scan

A business-language diff of the business rules added, modified or removed between two scans.

A living portal

The whole team reads the same documentation in a secure web portal, current with every scan.

Questions, answered with citations

Intelligence plan: the Help Agent answers with citations, also from Claude, ChatGPT, Cursor and GitHub Copilot over MCP.

Explore the platform See an example org

The first week of a takeover

From read-only access to a prioritised list of risky areas.

Connect read-only

Install the aprity managed package and authorise its read-only connected app, which uses JWT Bearer authentication. No user password is stored.

Scan

aprity reads the org's metadata — never the records — computes the dependency graph and documents what it finds.

Explore the portal

Walk the objects, automations, business rules and integrations with the team, in business language, from one place.

Prioritise the risky areas

Use the execution graphs, integration map and impact analysis to decide what to stabilise first and what to leave alone.

Before a change, run an impact analysis on the field or class you are about to touch. For the manual method and its limits, read our guide on finding everywhere a Salesforce field is used.

Who reaches for it

Built for the team that inherits the org.

System integrators and consulting firms

Start a new client engagement from a shared, current picture of the org instead of a discovery phase spent reverse-engineering it.

Managed-services and run teams

Onboard a support contract with the automations, rules and integrations already mapped, and re-scan on demand, up to once a week, as the org evolves.

Internal teams after a vendor leaves

Take the org back in-house with documentation that describes what is actually deployed, not what the last statement of work intended.

See the agents Compare plans

What it isn’t

A map of the org — not a replacement for the people who use it.

Not a data migration tool — it does not move records or deploy metadata.
It never modifies the org: the connector is read-only and reads metadata, not business data.
It does not replace talking to users: intent is documented only where the org states it, in descriptions, help text, error messages or code comments.
One org per plan. The free trial documents up to 3 objects you choose and runs up to 2 scans.

The access model, data residency and purge policy are set out on the security page. If the takeover also has to satisfy an auditor, the same baseline supports a Salesforce org audit.

Questions

Salesforce org handover — FAQ

How do you take over an undocumented Salesforce org?

Start from what the org actually contains, not from what people remember. Map the objects and fields, the automations that fire on each object and in which order, the business rules and where they live, and the systems the org exchanges data with. aprity builds that map from the metadata with read-only access, so the new team starts from a reproducible baseline instead of weeks of manual archaeology — then uses interviews to fill in the intent the metadata cannot state.

Does aprity change anything in the org we are inheriting?

No. The connector is read-only and reads metadata only — object definitions, field schemas, automation configuration and code — never the business data in your records. Nothing is written back to the org, and the raw metadata is purged after every scan; only the derived documentation is kept.

Can aprity explain why the org was built the way it was?

Only where the org says so. Intent is documented when the org states it — in descriptions, help text, validation error messages or code comments. Where the metadata is silent, aprity documents what a component does and does not invent a reason. That is exactly the gap to close with the people who use the org.

What does the free trial cover for a handover?

The 14-day trial runs on your own org and is activated after a quick review, usually within one business day. It covers up to 3 documented objects (you choose which) and up to 2 scans, so pick the objects you are most worried about. Paid plans document the whole org, one org per plan, with a re-scan you can launch on demand up to once a week.

Is aprity a data migration tool?

No. aprity documents how an org is built and how it behaves; it does not move records, deploy metadata or modify configuration. Use it to understand what you are taking over and what a change will touch, alongside your usual deployment and data tooling.

Can the whole team ask questions about the inherited org?

On the Intelligence plan, the Help Agent answers questions about the documented org with citations to the components it relied on, and the MCP Remote Server lets the team query the same documentation from Claude, ChatGPT, Cursor and GitHub Copilot.

Start the takeover

Map the org before you change it.

Free 14-day trial on your own org, activated after a quick review — usually within one business day. No credit card. Read-only access, and metadata is purged after every scan.