Data model
The event, change package, and change levels that make up an audit trail entry.
Every audit trail entry starts as a chain: one occurrence of a Flow run, a Schedule execution, an API call, or a manual action. A chain represents one execution; older UI versions call it an event.
A chain groups its changes by both operation and identity:
- Operation — one connector call against one object in one destination. Its changes share an operation ID and record their pipe and valve origin.
- Change package — changes concerning one identity in one destination within a chain. One operation can span several packages, for example a group-membership write concerning several people.
- Change — one field-level write: which field, its value before and after, which object it was written to, and whether it succeeded.
A change package also carries a package type — a short code such as UserCreated or GroupMembershipAdded that the UI turns into a readable label like "Created user" where a label is defined, and shows as-is otherwise.
Where chains come from
Section titled “Where chains come from”| Source | What starts a chain | Initiator shown |
|---|---|---|
| Flow | One Flow run | The signed-in user who ran the flow |
| Schedule | One scheduled job execution | The schedule itself |
| API | One API call | The calling integration, or a person named in the request if it asserts it acts on their behalf |
| Manual | A change made outside the usual entry points | Depends on how the change was recorded |
Enrichment
Section titled “Enrichment”Changes are recorded with the raw values a connected system actually used — an LDAP distinguished name, a raw attribute name, a technical field identifier. When the module's LDAP enrichment is configured for an object type, those raw values are paired with human-readable ones: a person's display name instead of their DN, a field label instead of its raw attribute name. Enrichment is best-effort — if a lookup fails, the raw change is still recorded, only the enriched values are missing.
Enrichment also determines who a change is attributed to. A write to a group's membership list, for example, is attributed to the person added or removed, not to the group — even though the group is what was technically written to. See Enriching LDAP changes for how this is configured.