.svg?fit=max&auto=format&n=mPHHzoA5GT4E38PL&q=85&s=476f5e0f52403962a9938292fd13cf9b)
.svg?fit=max&auto=format&n=mPHHzoA5GT4E38PL&q=85&s=d9661161e773aa91cc1f45d852fc9825)
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.Vault
Creating or deleting a vault follows the standard pattern for most organisations. On approval: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:
Activation, deactivation, recovery, and role changes each follow the standard Requested → Approved/Rejected → Applied pattern, with these specifics:
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: Changes 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.