Skip to main content

Functional Processes

When you open your aprity documentation, alongside the per-object pages (Account, Opportunity, Case, …) you'll find a Processes section that documents the cross-object business flows in your org : Lead-to-Opportunity, Quote-to-Cash, Case-to-Resolution, Customer-Onboarding, and so on.

A Functional Process is the answer to "What happens when a Lead is converted ?" -- not just on the Lead object, but across every object, automation, and integration that fires as part of that flow. aprity infers these processes deterministically from your metadata (entry points, triggers, flows, validation rules, integrations) and renders them with a Mermaid diagram and a phase-by-phase narrative.

What you'll see​

Each process page is structured the same way :

  1. Title and short description -- "Lead conversion : how a Lead becomes an Account / Contact / Opportunity in this org."
  2. Trigger object and entry point -- where the process starts (a Lead UPDATE, a scheduled job, an inbound REST call, …).
  3. Cross-object diagram -- a Mermaid flow chart showing every object touched, in order, with phase grouping.
  4. Phase-by-phase walkthrough -- for each phase (typically Validation, Conversion, Post-processing, Notification, …), the list of automations that fire and the records they read or write.
  5. Linked rules -- direct links to the validation rules, triggers, flows, and integrations that participate in the process.
  6. External systems involved -- if the process publishes a Platform Event, calls a Named Credential, or receives an inbound REST call, the connected External System is named (DocuSign, SAP, Stripe, …).

How processes are detected​

aprity does not invent processes. The Functional Process list is the result of three deterministic signals from your scan :

  • Entry points -- every trigger, screen flow, scheduled job, REST endpoint, batch class, and platform-event subscriber declared in your metadata.
  • Dependency edges -- which automation reads or writes which object, computed from the Salesforce Tooling API and from parsing the Apex / Flow XML.
  • Theme clustering -- automations that share entry conditions, that write to the same set of objects in the same order, or that share a known business theme (conversion, onboarding, scoring, billing, …) are grouped into one Functional Process.

The result is conservative : a Functional Process page only exists when there is enough concrete evidence in your org to support it. If a flow you expect is missing, the most common reasons are that it crosses too few objects (it lives on a single object page), or that the relevant metadata was outside the scan scope.

Plan availability​

Functional Processes are generated on every plan. The output language follows your plan's language settings -- all six languages are available on every plan.

Where to find them​

  • Customer Portal : the Processes entry in the sidebar. See Customer Portal.
  • StorySite export : Functional Processes become the EPICs of the backlog -- one EPIC per process, with FEATURES grouped by phase. See StorySite — Backlog export.
  • Help Agent / Story Agent : the agents are aware of Functional Processes and will cite the relevant process when answering a question or generating a story.

How to use them​

A Functional Process page is the right starting point when you need to :

  • Onboard a new team member -- read 5–10 process pages to grasp the org's business logic in an afternoon.
  • Plan a refonte or migration -- each process maps directly to an EPIC in the target system. See the StorySite for a backlog-shaped view of the same information.
  • Diagnose an incident -- "Why did the Opportunity not update when the Quote was approved ?" -- find the process, follow the phase-by-phase walkthrough, identify which automation should have fired.
  • Audit business logic -- demonstrate to a compliance reviewer or auditor that a given rule (e.g. "no Opportunity above 100k closes without a Manager approval") is enforced in a specific phase of a specific process.
  • Document changes -- when you're about to refactor a flow, read the process pages that involve it first to understand the downstream impact.

Limitations​

  • A process is only generated when the cross-object evidence is strong enough. Single-object behaviours stay on the object page.
  • The phase labels (Validation / Conversion / Post-processing / …) are heuristic and may not match your team's internal vocabulary. You can submit feedback on a process page to suggest a renaming.
  • Mermaid diagrams have caps (30 phases per diagram, 6 objects per phase node) to stay readable. Very large processes are split into multiple diagrams.

For anything else, contact support@aprity.ai.