Skip to main content

ADR-007: Execution Relationship Types

Status​

Accepted (2026-02-13)

Context​

With entity type reclassification (ADR-006), the execution chain now traverses 4 different entity types: automation, connection, credential, and identity. The existing edge types are overloaded:

  • EXECUTES_ON connects both automation-to-resource and automation-to-connection, with no type distinction. A Business Rule "executing on" a REST Message is semantically different from a Business Rule "executing on" the incident table.
  • AUTHENTICATES_VIA was a catch-all for two semantically different relationships: (a) connection-to-credential (REST Message → OAuth Profile, meaning "uses this auth material") and (b) identity-to-credential (meaning "authenticates with this credential"). These have opposite data-flow directions and different security semantics — conflating them made typed traversal impossible.

The full execution chain in a ServiceNow-to-Entra scenario follows this path:

Business Rule → Script Include → REST Message → OAuth Profile → Service Principal → Entra ID
(automation)    (automation)     (connection)    (credential)    (identity)         (resource)

Each arrow represents a different semantic relationship. Using a single edge type for all of them loses the semantics that enable typed traversal, constraint validation, and clear evidence chains.

Decision​

New relationship types​

Add 4 new relationship types to model the typed execution chain:

Edge TypeFrom TypeTo TypeSemanticsExample
CALLSautomationautomationCode invocation — one automation triggers or calls anotherBusiness Rule invokes Script Include
INVOKESautomationconnectionOutbound call — automation uses a connection config to make an external requestScript Include calls REST Message
USESconnectioncredentialCredential binding — connection config references auth materialREST Message uses OAuth Profile
AUTHENTICATES_AScredentialidentityIdentity resolution — credential represents a specific authenticating identityOAuth Profile authenticates as Service Principal

Updated existing relationship types​

Edge TypePrevious ConstraintNew ConstraintChange
RUNS_ASautomation → identityautomation → identity | ownerExtended to cover flow run-as human user
EXECUTES_ONautomation → resource | connectionautomation → resourceNarrowed — automation-to-connection now uses INVOKES

Deprecated relationship type​

Edge TypeLegacy UsageReplacementMigration
AUTHENTICATES_VIAconnection → credentialUSESIngestion normalizer remaps on ingest during migration window
AUTHENTICATES_VIAidentity → credential(removed)Path is now reversed: credential → identity via AUTHENTICATES_AS

Preserved relationship types​

  • AUTHENTICATES_TO — cross-system identity-to-identity authentication (e.g., Entra Service Principal authenticates to ServiceNow Integration User). This is distinct from AUTHENTICATES_AS (credential-to-identity binding within a system).
  • OWNED_BY — entity-to-owner ownership relationship
  • HAS_ROLE — identity-to-role assignment
  • GRANTS — role-to-permission grant
  • CREATED_BY — entity-to-owner creation provenance
  • TRIGGERS_ON — automation-to-resource trigger binding

Full edge migration mapping​

Legacy EdgeLegacy UsageNew EdgeCondition
EXECUTES_ONautomation → REST MessageINVOKESWhen target is connection type
EXECUTES_ONautomation → table/resourceEXECUTES_ON (kept)When target is resource type
AUTHENTICATES_VIAREST Message → OAuth ProfileUSESAlways (connection → credential)
AUTHENTICATES_VIAidentity → credential (legacy)(removed)Path reversed: credential → identity via AUTHENTICATES_AS
(none)--CALLSNew: automation → automation (BR → SI)
(none)--AUTHENTICATES_ASNew: credential → identity

Typed execution chain traversal​

With these edges, a full execution chain traversal follows a deterministic typed path:

automation --CALLS--> automation --INVOKES--> connection --USES--> credential --AUTHENTICATES_AS--> identity --HAS_ROLE--> role --GRANTS--> permission --APPLIES_TO--> resource

Each hop has a known from-type and to-type, enabling:

  • Type-safe BFS in the path materializer
  • Validator rules that reject edges with wrong from/to types
  • Clear evidence chains where each edge type explains the relationship

Consequences​

Positive​

  • Graph traversal follows typed edges — each edge type has clear from/to type constraints, enforceable by validators
  • Evidence chains are self-documenting — reading "INVOKES" immediately tells you an automation is calling a connection, not executing on a resource
  • Path materializer can use edge type as traversal hint — BFS knows what entity type to expect at each hop
  • AUTHENTICATES_TO preserved for cross-system auth — no ambiguity between "credential authenticates as identity" and "identity authenticates to external system"

Negative​

  • Path materializer must follow the new edge sequence — existing traversal logic that follows EXECUTES_ON chains must be updated
  • Migration window complexity — platform must accept old + new edge types simultaneously; ingestion normalizer remaps legacy edges to new types
  • More edge types to document and maintain — 4 new types added to the relationship vocabulary

Neutral​

  • Connector changes are additive — connectors can emit new edge types immediately; legacy edges are remapped by the platform during migration

When to Reconsider​

  • If a new source system introduces edge patterns that don't fit the typed chain (e.g., a credential that directly invokes a connection)
  • If the number of edge types grows beyond manageable complexity (current total: ~12 relationship types)

Analysis​