OmniStudio

If your org uses Salesforce OmniStudio, aprity documents it in the OmniStudio & rules domain of the portal. The documentation is built from the configuration captured by the scan; it is included on every plan and needs no setup.

What is documented

Family	What you get
Journeys	One page per journey -- an OmniScript that no other script embeds. The entry point for readers.
OmniScripts and Integration procedures	One page per script or procedure, with its steps, calls and the objects it reaches.
Data mappings (Data Mapper / DataRaptor)	Objects read or written, and the field mapping.
Cards (FlexCard)	Type, version, data source and configured card states.
Rule sets (Expression Set)	Versions with their validity dates, and the ordered steps of each version.
Decision matrices	Versions, dimensions, the reference rows captured, and which components use them.

Journey pages

A journey page describes a complete guided process as the user experiences it:

• At a glance -- the number of screens, fields filled in, integration procedures, rate tables read and data mappings called.
• The walkthrough -- the screens in their configured order.
• Behind the scenes -- what the journey calls: integration procedures, data mappings, rate tables, Apex.
• What this journey mobilises -- the components involved, with their activation state.
• Where this journey is called -- its launch points: page placements, page assignments, quick actions, Experience sites and incoming calls from other components.
• Sibling journeys, Reading limits, and a technical appendix listing the components of the journey.

From a journey you can drill down to a screen and then to a field (where it is used, its conditions).

Data mappings, rule sets and rate tables

• Data mapping pages show whether the mapping reads, writes or only transforms data, the Objects touched, the Field mapping (source and target, in declared order), upsert keys, and the scripts and procedures that run it.
• Rule set (Expression Set) pages list the Versions with Valid from / Valid to, then the rules of each version as an ordered tree of conditions, assignments and rate-table lookups.
• Decision matrix pages list the versions, the dimensions, the captured reference rows and the consumers. A disabled version is flagged as not being the scale in force.

Reading the pages correctly

• Configured order is not an execution trace. Screens and steps are shown in the order they are configured. That order does not prove which path a user actually takes.
• Activation is shown, not hidden. Inactive scripts, mappings and cards are still documented, flagged Disabled in configuration. When the activation could not be read, the page says Activation unknown rather than assuming either way.
• A launch point proves configuration, not usage. A component placed on a page shows how the page is configured, not who uses it. When no launch point is found, the page says so -- this is not evidence that the journey is unused.
• Not measured is not zero. When the scan could not measure something, the page says Not measured.
• No price simulation. Rate tables are documented as captured; aprity does not evaluate them to compute a price.

Deterministic by default

The OmniStudio pages are built from your configuration, without AI. When no explanation written by your authors is available, the page shows the structured facts only.

Using it with the AI assistants

The Org Expert and the Remote MCP Server can answer questions about OmniStudio processes (screens, fields, conditions, calls) and rate tables (versions, validity dates, dimensions, consumers). The Migration backlog tags OmniStudio-based stories as OmniStudio to reimplement.

Limitations

• aprity documents the standard OmniStudio runtime. Content of the older managed OmniStudio (Vlocity) packages is not published.
• When several versions of a component exist, aprity documents the active one, or the most recent if none is active.
• Very large field mappings and rate tables are shown with a row count (for example "rows shown out of total").