Skip to main content

Technical Appendix and Technical Details

aprity documentation is written for business analysts first. Implementation details that do not express a business decision are kept, but set apart, so readers can skip them and developers can find them.

The technical appendix of an object page​

Some rules found in code are safety mechanisms rather than business rules: null checks, type checks, framework invariants. aprity classifies them as technical guards and lists them at the end of the object page, under Technical appendix, with their condition and action.

This keeps "the code prevents an error" from being read as "the business requires this". A business analyst can usually skim this section. When an object has no technical guard, the section is not shown.

In the rule register of an object, you can also group rules By nature to separate business rules from technical ones.

Apex security signals​

For the Apex classes involved in an object's automations, the object page shows Apex security signals:

  • the sharing mode of each class (with sharing, without sharing, inherited sharing) -- without sharing classes bypass record-level access controls;
  • whether a recursive guard is active.

These are detected statically in the code.

Component pages​

Apex classes, batch and scheduled jobs, screen flows and other components have their own pages in the documentation, reached from the domains of the portal (for example Batches or Screen Flows) and from the links on object and process pages. The execution graph shows how they connect to each object.

What the documentation does not contain​

  • The full source code. Use your Salesforce tools for that.
  • The internals of managed packages, which are excluded by default.
  • A prediction of paths decided at runtime by code (dynamic queries or class names). They are flagged rather than guessed.