Inherited a Salesforce org? Start with a first-week discovery plan.
A list of components is a starting point. Your first deliverable should explain which processes matter, who owns them and what still needs investigation.
6 min readBegin with read-only discovery, identify the owners of critical processes and trace one representative journey end to end. Record the environment, retrieval date and evidence for each finding before proposing changes.
Use the five-day sequence below as a planning template, not a promise that every org can be understood in a week. A complex estate may need several iterations; missing access or unavailable owners should stay visible in the handover.
A practical first-week sequence
Day 1: establish scope and ownership
Confirm which production org and sandboxes you are taking over, who authorises access, and where incidents and releases are recorded. Ask for the business-critical processes and upcoming deadlines. Record access gaps without expanding your permissions by default.
Day 2: capture a dated configuration baseline
Inventory the objects, active automation, validation rules, Apex, packages and integration configuration you can access. Keep API names and versions alongside readable names. Retain retrieval errors and excluded metadata types so an incomplete inventory cannot look complete.
Day 3: trace one business journey
Pick a journey with its business owner, such as lead qualification or case escalation. Follow the objects, entry conditions, automation and external boundaries. Separate what the source establishes from the reason the business chose that design.
Day 4: validate operational responsibilities
Ask who monitors scheduled jobs, failed integrations and releases. Identify the locations of approved runbooks and credential-management procedures; do not copy secrets into the handover. Confirm who can restore service and who approves changes.
Day 5: review gaps and agree the next scope
Walk the receiving team through the baseline and the chosen journey. Assign each unanswered question an owner and next action. Obtain acceptance for the documented scope, not for a claim that the whole org is now understood.
Make uncertainty actionable
For each finding, store the component API name, environment, source location, capture date, observation, reviewer and open question. Useful statuses are verified from source, confirmed by an owner, requires runtime verification, and not reviewed.
For example, a Flow may visibly update an Opportunity field. Its metadata does not by itself establish which external service later reads that field, whether the path ran yesterday or why the business wants it. Those are separate questions with separate evidence.
What to postpone until discovery is reviewed
Treat deletion, automation consolidation and access redesign as later decisions. A missing reference in a retrieved corpus is not sufficient evidence that a component is unused. Add proposed changes to a backlog with the observations that prompted them.
A successful first handover leaves the next person able to locate the source, contact an owner and continue the investigation. Use the downloadable kit to capture those responsibilities and acceptance criteria.
Free working files
No registration required. Work locally and keep your organisation’s details private.
References and further reading
Start the handover from generated documentation
Aprity provides a documentation portal derived from your Salesforce metadata. Use it to explore objects, automation and business-rule explanations, then review the selected scope with the receiving team.
- Keep source references with the explanation
- Review a known process during the trial
- Add ownership and decisions with your team
Inherited a Salesforce org? Start with a first-week discovery plan. — FAQ
Should I clean up the org immediately?
Start with a dated baseline and ownership review. Decide on changes only after the relevant dependencies, usage evidence and validation needs have been investigated.
Can a metadata scan replace the outgoing team's handover?
It can reconstruct accessible configuration. It cannot reliably reconstruct undocumented business decisions, external ownership or every operational exception.
Related guides
A Salesforce handover the next team can actually use.
Give the receiving team a route from a business question to a named owner and a verifiable source. Download the working kit without a form.
Read the guide GuideHow to document a Salesforce Flow
Flow Builder shows you the canvas. It does not tell you what the Flow changes, what it depends on, or what breaks when you edit it — and those are the three things anyone reading the documentation actually needs.
Read the guideSee it on your own org, not on a slide.
A free 14-day evaluation documents your org from a computed dependency graph — read-only, no credit card, and you review the output before deciding anything.