Audit
The Audit page (/org/audit) is the record of your organization's administrative actions: who created a user, who published a skill, who changed a profile. It's your trail for answering who did what, when, and on which target.
This log covers the administrative operations in the /app console. It is not a usage or billing screen — Imaginne does not expose consumption metrics or billing to the organization administrator. Administrative visibility is limited to the Dashboard cards and this record.
Filters
The list can be refined by:
- Action — narrows to a single event type (for example,
user.created). - From / to date — limits the time range.
Columns
Each event appears as a row with:
| Column | Content |
|---|---|
| Time | When the action occurred. |
| Action | The event type (see the list below). |
| Actor | Who performed the action. |
| Target | The affected object (user, profile, skill, group, etc.). |
| Details | Additional information about the change. |
Recorded actions
The log covers the main administrative operations, grouped by area:
| Area | Actions |
|---|---|
| Users | user.created, user.updated, user.disabled, user.activated |
| Profiles | profile.* (creation, update, assignments) |
| Skills | skill.created, skill.updated, skill.published, skill.archived, skill.rolled_back |
| Skill groups | skill_group.* (creation, update, admins, skills) |
| Organization | org.* (organization configuration changes) |
When a skill disappears from a team's sessions or a user loses access, the audit usually has the answer: look for skill.archived, profile.*, or user.disabled in the relevant range, and check the Actor and the Details.
How to read an entry
Each row answers four questions, in the order of the columns. Take a common case — an archived skill:
- Time — when: the moment of archiving.
- Action — what:
skill.archived. - Actor — who: the administrator (or skill administrator) who performed the action.
- Target — on what: the affected skill.
- Details — the context: for example, the version involved.
Reading the columns together, you reconstruct the change without needing another source. To cross-reference with the effect users felt, remember that changes to skills, profiles, and groups recompute the effective policy and reflect on the next session sync.
Best practices
- Start with the range. Filter by from / to date around the moment the problem appeared; this cuts the noise before you filter by action.
- Combine action + actor. For accountability, filter by Action and check the Actor of each event.
- Correlate across areas. A symptom in one area often has its cause in another: "user with no skills" may come from
profile.*(a changed profile) or fromuser.disabled. - Trust the record, not memory. Since the console doesn't delete users (only deactivates them), history stays consistent — the audit is the definitive reference for what changed.
See also
Was this page helpful?
Report a problem on this pageDo not send passwords, keys, tokens, or customer data.