Practical guides for people who have to understand an org.
Document an inherited org, prepare its handover, check AI-generated documentation and build an audit evidence pack. Practical methods, native-tool limits and free working files for Salesforce teams.
Start here
Each one answers its question first — the native tooling, its real limits, and the manual method — before it says where aprity fits.
How to document a Salesforce org around decisions people need to make
Build org documentation from a dated source baseline, a worked business journey and reviewable behaviour contracts. Separate configuration, intent and operational evidence.
Salesforce documentation template: turn a component description into a review contract
A downloadable Markdown template with a filled example, source register, behaviour contract, claim ledger, acceptance cases and change history.
Salesforce documentation example: read a validation rule without overstating it
A worked validation-rule analysis with boundary cases, transition semantics, counterexamples and explicit limits. Download the synthetic metadata source.
Flow documentationDocument a Salesforce Flow so another engineer can challenge it.
A screenshot can show a route through Flow Builder. It cannot explain which record changes enter that route, what happens on a second update, or which failures leave work unfinished. Those are the questions your documentation needs to answer.
Find where a Salesforce field is used—and what your search cannot establish.
A blank dependency result is easy to misread as permission to delete a field. A useful investigation instead identifies the proposed change, collects several kinds of evidence and assigns an owner to the gaps.
Prepare Salesforce evidence an ISO 27001 auditor can follow.
A configuration export can show how an org was set up on a date. It cannot show that access was reviewed, a change was approved or a recovery procedure worked. Build the evidence pack around the questions being assessed.
Inherited a Salesforce org? Find what could stop the business first.
The first week is usually too short to understand an established org. It is enough to discover which services depend on it, who can recover them and which assumptions need urgent investigation.
A Salesforce handover kit the receiving team can actually use.
A folder of diagrams can be delivered while the incoming team still cannot explain a failed order. Treat the handover as a transfer of operating responsibility, with a practical exercise that shows what has—and has not—been transferred.
Evaluate AI Salesforce documentation beyond fluent explanations.
An explanation can be readable, well formatted and wrong about the condition that matters. Evaluate whether a reviewer can rely on its claims, find its omissions and correct it without reconstructing the whole component.
Audit whether your Salesforce documentation can support a real decision.
A documentation audit should uncover where a reader would make the wrong change, misunderstand a process or be unable to investigate a failure. Counting documented components is only the beginning.
Need a definition first? Browse the Salesforce glossary →
What aprity does about each of these
The guides stay out of the sales conversation. These pages are the sales conversation.
Automated Salesforce documentation
Explore supported Salesforce metadata and source-linked explanations in a documentation portal.
See the pageSalesforce org handover
Take over an org you did not build: its objects, automations, business rules and integrations, documented read-only.
See the pageSalesforce org audit
Organise configuration documentation alongside the operating evidence your audit team requires.
See the pageSelligent to Salesforce migration
Document a legacy Selligent CRM read-only and turn it into a grounded migration backlog.
See the pageOr stop reading about it and look at your own org.
A free 14-day trial, read-only, no credit card. You review the output before deciding anything.