Skip to main content

Technical Appendix

On every object page in your aprity documentation, a Technical Appendix section sits below the business-level narrative. It documents the implementation-level details : which Apex triggers fire, which Flow elements execute, which fields participate in which automation, which Apex classes own the cross-object work.

Where the main object page answers "What does this object do for the business ?", the Technical Appendix answers "How is it implemented under the hood ?". It is meant for the audience that has to read or change code -- developers, architects, technical BAs, migration engineers.

What you'll see​

The Technical Appendix on a typical object page contains :

  1. Triggers -- every Apex trigger declared on the object, with its event signature (BEFORE INSERT / AFTER UPDATE / …), the helper class it delegates to, and the order in which it runs relative to other automations on the same event.
  2. Flow handlers -- every record-triggered flow declared on the object, with its trigger conditions, save order, and the elements that read or write child records.
  3. Apex services -- the Apex classes invoked by the triggers and flows (handler classes, services, integrations). Each linked to its own page in the documentation.
  4. Field references -- which fields are read by which automation, which are written, which participate in validation rules, which are exposed in REST endpoints.
  5. Test coverage hints -- when the org has Apex test classes targeting these automations, they're listed so you can find the spec they encode.

The section also calls out any technical guards -- code that exists for safety but doesn't enforce a business rule (idempotency checks, retry logic, error-handling fallbacks, recursion guards). These are flagged separately from the business rules so a reader doesn't confuse "the code prevents reprocessing" with "the business requires reprocessing not to happen".

What's not in the appendix​

The Technical Appendix is the implementation map, not a code dump. It does not :

  • Reproduce the full Apex source code (use Salesforce Developer Console / VS Code for that).
  • Document the third-party dependencies of your Apex code (managed packages, libraries).
  • Predict runtime behaviour for dynamic SOQL or dynamic Apex paths -- those are flagged as "dynamic" with a pointer to the source.

Plan availability​

The Technical Appendix is part of the Technical Analysis feature, which is included on every plan:

  • Trial -- included.
  • Documentation -- included.
  • Intelligence -- included.

See Plan Comparison for the full feature matrix.

Where to find it​

  • Customer Portal : the Technical anchor at the bottom of every object page. See Customer Portal.
  • StorySite export : the appendix details flow into the technical complexity hints on each USER STORY (T-shirt sizing), so a migration estimator can use them without opening the documentation.
  • Help Agent / Story Agent : the agents can cite Technical Appendix content when an answer requires implementation detail.

How to use it​

The Technical Appendix is the right starting point when you need to :

  • Refactor or rewrite an automation -- list every consumer of the affected fields and the test classes that pin the current behaviour before touching anything.
  • Estimate a migration to another platform -- the appendix tells you how many Apex classes, Flow elements, and field references each object carries, so you can size the work.
  • Diagnose a deployment failure -- "Why does this Apex test fail after the deploy ?" -- the appendix names the test classes against the affected automations.
  • Onboard a new developer -- skim the Technical Appendix on the top 5–10 objects to grasp the codebase's structure in an afternoon.
  • Audit code-level compliance -- demonstrate that a given business rule is enforced by code (not just by user training) and that the code is covered by tests.

Limitations​

  • Apex code targeted by dynamic SOQL or dynamic Apex (Type.forName(…), Database.query(…)) is documented with a "dynamic" marker -- aprity does not execute your code to predict the runtime callsite.
  • Test coverage is reported from the static @isTest annotations and Test.startTest() / Test.stopTest() boundaries observed in code, not from the actual coverage percentages reported by Test.deploy(…). Coverage percentages can vary based on which test runs you actually execute.
  • Third-party managed packages are documented up to their public surface only -- aprity does not introspect inside a managed-package namespace.

For anything else, contact support@aprity.ai.