Skip to main content

Integrations and Integration Map

When your org exchanges data with other systems -- an e-signature provider, an ERP, a payment service, an in-house middleware -- aprity documents each of them. The Integrations & API domain of the documentation answers questions such as "how does our org talk to this system, and what triggers the exchange?"

It is included on every plan.

What you find in the Integrations & API domain​

  • One page per external system, describing what is exchanged, in which direction, when it fires, and which Salesforce components are involved.
  • Exposed APIs -- the REST endpoints your own org publishes (Apex REST resources), with their supported methods and example payloads found in the code. These are surfaces your org offers; aprity does not guess who calls them.
  • Connected apps, Consumed services and Events -- the related configuration and event channels.
  • Declared but unused metadata -- named credentials, connected apps, external data sources and platform events declared in the org but with no observed call. They are listed so you know they exist, without inflating the list of active integrations.
  • Outbound calls (unattributed) -- calls whose target system could not be identified from the metadata, each listed with its caller and transport, rather than being given an invented name.

How systems are discovered​

aprity names a system only from evidence in your org:

  • Apex code -- outbound calls (callouts through named credentials, URLs written in the code), REST endpoints, and event publication and subscription.
  • Configuration -- named credentials, external credentials, connected apps, and routing records that tell which credential a call uses.
  • Platform events -- declared publishers and subscribers.

A system appears only when at least one call to it is observed. Several credentials of the same provider (for example one account per brand) are grouped under one system. A platform event whose publishers and subscribers are all inside your org is internal messaging, not an external system, and is documented in the events section only.

A system page​

Each system page covers:

  • a description of the integration and its use case, written from the evidence found,
  • its direction (outbound, inbound, bidirectional, event),
  • the flows: outbound callers, inbound endpoints, event publishers and subscribers,
  • the service class that handles it, the credentials and connected apps involved,
  • the objects impacted and the related business rules.

The integration map​

The Integration map gives a visual overview of every external system with an observed call. Open it from the Integrations & API domain of the documentation.

  • Switch between Graph and Table views.
  • Filter by Direction and by Category (Business partner, Infrastructure, Internal tooling, Other).
  • Use Zoom in, Zoom out and Fit to navigate.
  • Click a system to open its System detail: description, use case, business domains, impacted objects, flows, service class and data classification.

The legend distinguishes synchronous links (REST/SOAP) from platform events (asynchronous). A system marked Declared, unused has configuration but no observed call.

If your team has written a precision on an integration through feedback, it is shown with a [Your team] marker, next to what aprity computed.

Where integrations are also used​

  • Migration backlog -- each external system becomes an integration epic. See Migration Backlog.
  • Org metrics -- the number of external systems appears on the Overview.
  • AI assistants -- the Org Expert and the Story Agent can answer questions about a given integration.

Limitations​

  • An integration needs at least one observable call, endpoint or event in the code. Declared configuration alone stays in the unused list.
  • Endpoints built at runtime by code cannot always be attributed to a system; they appear under unattributed calls.
  • aprity does not contact the external systems. The documentation describes what your org is configured to do, not whether the other system currently responds.
  • Configuration of managed packages is excluded by default.