Appendix: Event reference

this lists every message shown in the activity column, grouped by entity, with what triggers each one transaction transactions use their own wording ("submitted," "received") rather than generic create/approve/reject terms, and the final status update is written by the system rather than a user message trigger transaction created a transfer or trade is submitted and enters the approval queue transaction approved an approver approves the pending transaction transaction rejected an approver declines the transaction, or its approval window expires reserved spend is released back to the policy budget transaction submitted approval completes and the transaction moves to processing in most cases this means it's queued for dispatch, but a deposit can be marked approved under this same message without actually being dispatched transaction received an inbound transfer into an org wallet finishes processing system generated and no user shown transaction status updated an outgoing transaction reaches a terminal state on chain system generated outcome reads success if it completed, failure if it failed onchain "transaction created" is used for both outgoing transfers and completed incoming transfers being logged for the first time; direction, not the label, is what distinguishes them "transaction rejected" always refers to an approval decision, never an onchain failure vault creating or deleting a vault follows the standard pattern for most organisations on approval message trigger vault created the vault is fully provisioned exchange linking, permissions, wallet generation, and contract deployment all happen at this point vault deleted the vault is detached from every policy rule and group referencing it, its pending transactions are rejected, and each detached policy or group gets its own entry some organisations create and delete vaults with no approval step for those, you'll only ever see the single "vault created" or "vault deleted" entry, with no requested or approved entries before it policy policy changes always require approval a policy rule is never created or edited outright (the entity is labelled "policy," not "policy rule ") changing a vault's policy template also follows the standard pattern, logged as vault update requested / approved / rejected / updated creation and updates follow the standard pattern two things are specific to policies there is no delete action deleting a policy is logged as policy update requested → policy updated most "policy updated" entries aren't edits at all deleting or deactivating something a policy references — a user, contact, vault, or dapp — automatically removes it from every policy that mentioned it each affected policy gets its own "policy updated" entry, attributed to whoever requested the original deletion, not to a policy editor policy template creating a template is immediate with no approval required, so only policy template created is logged editing a template follows the standard pattern (update requested / approved / rejected / updated), and an applied edit propagates to every vault using that template admin policy the org level policy governing approvals always exists, so there's no create or delete action — only the standard update pattern (admin policy update requested / approved / rejected / updated) user user events follow several distinct flows, since different account changes have different approval requirements invite and resend no approval required message trigger user invited an admin invites someone into the org, or an api user is created user invite resent the invite is re sent to a user still pending onboarding doesn't fire if that user already has an activation request pending activation, deactivation, recovery, and role changes each follow the standard requested → approved/rejected → applied pattern, with these specifics flow what "applied" means activation the user is granted their permissions and marked active skipped entirely (no entries at all) if the org has no other active admin available to approve it deactivation the user is marked inactive, their pending transactions are declined, and their access is revoked access level change the user's new role takes effect recovery the user's old devices are cleared — this does not restore access, it only clears them to register a new device the message reflects this "user can be re activated " re activation after recovery raised automatically once the user registers a new device — this is the step that actually restores access, ending in "user re activated " a deactivation with no request or approval entries before it means the user was still pending onboarding when deactivated if a user entry reads plainly "user created," "user updated," or "user deleted," with no more specific wording, the log wasn't able to identify which of the flows above produced it, and fell back to a generic label the event still happened; the log just can't tell you which lifecycle it belongs to contact contacts (withdrawal addresses) follow the standard pattern in full for creation, edits, and deletion on deletion, the contact is detached from any policy rules or groups that referenced it contact group / vault group groups are only ever updated — never created or deleted as their own event the label shown depends on the group's members "contact group," "vault group," or "group" if that can't be determined both a rename and a membership change follow the standard update pattern two things to know a group's timeline can show changes nobody made directly adding a contact to two groups produces an "updated" entry on each group, alongside the contact's own entries a vault added to a group at creation doesn't generate a group entry — but the same vault being removed from a group later does bank account only creation is currently supported and there's no edit or delete flow yet dapp dapp allowlist entries are created and deleted through approval, never edited both follow the standard pattern on deletion, the dapp is removed from any policy rules that referenced it not currently logged policy sets c hanges appear on the related policy template or vault instead logins and report downloads most failed actions a validation error or permission denial that stops an action before it completes leaves no entry the one exception is an outgoing transaction failing onchain, captured as described under transaction above automations an approved automation is queued for later processing, so no "applied" entry is written at approval time