Skip to main content

Functional Processes

Object pages explain what happens on one object. Functional processes explain the business flows that span several objects: how a lead becomes a customer, how a contract is signed, how a claim is handled. They answer questions such as "what happens, from start to finish, when ...?"

You find them in the Processes domain of the documentation in the portal. They are included on every plan.

How processes are identified​

A candidate is kept as a process only when three signals are found together on the same group of objects:

  1. An object cluster -- at least three related objects (lookups, master-detail relationships, or a stable naming pattern).
  2. A process initiator -- a record-triggered flow, an Apex trigger handler, or a recurring batch, scheduled or queued job touching the cluster.
  3. An external touchpoint or an orchestrator -- a named credential, connected app, platform event, or a dedicated Apex service class wiring the cluster together.

The criteria are deterministic; an AI model screens the candidates against them and writes the prose. Distinct lifecycles that share a parent object (for example an amendment and a claim on the same contract) are documented as separate processes when each passes the test.

The approach is conservative: a flow that stays on one object is documented on that object's page, not as a process.

What a process page shows​

  • Description, Actors and Involved Objects.
  • Business Outcome -- what the process produces, when it can be derived from the rules.
  • Success Metrics (KPIs) -- only when a source in your org names them; otherwise the page says none was detected.
  • Process Phases, with an end-to-end diagram of the phases.
  • Risks and Related Technical Processes.
  • A sample of supporting rules for each phase, with links to the full lists on the component pages.

The steps​

When a detailed dossier is available, the page tells the process as a sequence of steps. For each step:

  • When it happens,
  • Depending on the case -- the variants,
  • What can block it,
  • What results,
  • the Rules of this step, with their exact conditions.

Open questions list what the documentation could not establish. The story is written by an AI model from the scan's rules, then reviewed by a model. The order of the steps relies on the Salesforce save cycle and on the rule conditions; it has not been verified by running the process. The page states this, and flags statements that were removed during review.

Where processes are used​

  • Migration backlog -- each process becomes an epic, with features grouped by phase. See Migration Backlog.
  • Org metrics -- the number of processes appears on the Overview.
  • AI assistants -- the Org Expert and the Story Agent can cite the relevant process.

How to use them​

  • Onboarding -- reading a handful of process pages gives a newcomer the business logic of the org.
  • Migration or rebuild -- each process is a unit of scope for the target system.
  • Incident analysis -- follow the steps to find which rule should have fired.
  • Before a change -- read the processes that involve a component before modifying it.

Limitations​

  • Processes are only documented when the three signals are present. If a flow you expect is missing, it may involve too few objects, or part of it may be outside the scan scope (see Coverage and Fidelity).
  • Phase and process names are written by AI and may not match your team's vocabulary. Declare your terms in your vocabulary or leave feedback on the page.
  • If the process map could not be produced for a version, the coverage page says so.