Analysis Strategy: When to Analyze and What to Review First
Each aprity analysis documents your whole org (up to 3 objects on the Trial). You do not choose what to document per analysis. What you plan is when to run the analysis and what your team reviews first.
Know your analysis budget
| Plan | Analyses |
|---|---|
| Documentation | 1 per week, at least 7 days apart |
| Intelligence | 1 per week, at least 7 days apart |
| Trial | 2 in total, at least 7 days apart, 3 objects documented in total |
An aprity Admin starts an analysis from the aprity app in Salesforce, with New Analysis. Analyses are not scheduled automatically: plan who starts them and when.
Pick the right moment
Because you have one analysis per week, run it when the org is in a stable state:
- After a release. Run the analysis once the release is deployed, so the documentation and the change history reflect it.
- Before a milestone. Run it a few days before a review, an audit or a migration workshop, so that the version you present is recent and has been reviewed.
- Not during a deployment. An analysis run while metadata is changing can document a half-deployed state.
Keep the same output language from one analysis to the next. The change history compares two versions only when they use the same language.
On the Trial
With 2 analyses and 3 objects, choose carefully:
- Pick the 3 objects with the most automation (validation rules, flows, triggers, Apex). They show the most value, because they are the hardest to understand by reading Setup.
- Use the first analysis to evaluate the documentation, the fidelity certificate and the AI assistants.
- Keep the second analysis to see how aprity reflects a change, for example after a small deployment.
What to review first
After the first analysis, review in this order:
- Org metrics (Overview): the size of your org, how much is custom.
- Your most critical objects: the ones that carry revenue, customer service or regulatory processes.
- Objects with the most automation: the object pages list rules by type, record type and trigger, and the execution graph shows the order in which they run.
- Integrations: the Integrations & API part of the documentation lists the external systems the org calls and the APIs it exposes.
- Coverage and fidelity: check what was documented, what was excluded, and the fidelity score, before you share the documentation.
Each week
- Open Coverage and fidelity > Versions to see what changed since the previous analysis.
- Review new or changed rules first.
- Handle new reader feedback in Human corrections before the next analysis, so that it is taken into account.
Common mistakes
- Using the two Trial analyses in the same week of testing. You cannot see how aprity reflects a change.
- Sharing a version before checking its coverage. A version marked Partial documentation has gaps; say so when you share it.
- Changing the output language between analyses. The change history cannot compare the two versions.