Three screens that have nothing to do with each other operationally and everything to do with each other in practice: they are how the organisation finds out what it did.
Audit center
Settings → Audit center, described as the cross-cutting audit trail. Every consequential action across the product, in one place.
This is the screen a compliance product is judged on, and it is worth knowing four things about it that are not obvious from looking.
Correlated events, and the trace timeline
An action is rarely one event. A dossier submitted fires a state change, an assignment, a notification and possibly an integration call — and reading them as four unrelated rows tells you almost nothing.
Two ways through it:
- Correlated events — everything sharing this event's correlation id. That is the business action.
- Trace timeline — everything sharing its trace id. That is the technical request.
When an event carries neither, the screen says so rather than opening an empty panel: this event has no correlation id, so there are no correlated events to open. And when only one row carries the identifier it says "Only this event carries this identifier — there is nothing else to show", which is a different fact from a search that failed.
The retention floor, and why it is stated
Each type of event can have its own retention period. When any type has one, the screen states the policy, one sentence per type — Activity events are kept for 90 days. — and only those types appear on that line: a type that does not appear is kept with no limit. When no type has a period, the line does not appear. By default, Activity and Exceptions have one, being diagnostics; entity changes and security events, which are the audit trail proper, do not.
More importantly: if you select a window that reaches further back than the trail exists, it says so: "The audit trail kept for this tenant begins on X. The window you selected reaches further back, so what you are seeing is not the whole story."
That sentence is the difference between an audit tool and a search box. A query returning nothing for last January could mean nothing happened, or that nothing is kept — and only one of those two answers should ever be given to an auditor.
Filtering has two halves, and the screen admits it
The server narrows by one event type and one severity at a time. Anything more specific is filtered in your browser, across the page you are looking at — and the notice says exactly that, along with how many of the events on this page matched.
So the count below a local filter is the unfiltered total, not the filtered one. Read the notice. A filtered view that silently reported a filtered count would be the most dangerous small lie this screen could tell.
Export stops, and says where
An export caps at a fixed number of rows: "Exported N of M audit events. The export stops at N rows — narrow the filters to export the rest."
A truncated export that did not say it was truncated is a spreadsheet somebody signs.
If you cannot open it
The screen says you do not have access to the Audit center — viewing the trail is its own permission, View Audit Trails, which the Auditor and Security Administrator templates carry. It is kept apart from granting access on purpose: whoever grants access is not who audits it. Chapter 14 is where that is granted.
Security
Settings → Security, under Personal settings, described as your account's security events. It is a specialised view of the same trail, and it asks for the same permission — View Audit Trails; without it, the entry does not appear in the menu.
It lists only the security events: sign-ins, failed or suspicious access, sensitive changes. It filters by date range, by user and by tenant, and has four figures at the top — Security events, High severity, Unique users, Latest event.
Changing your password and turning on two-step verification is not here: it is on the Security tab of the Account screen, which is another thing with the same name. The chapter Your account, the theme and your sessions describes both.
Notifications
Settings → Notifications is your own inbox — what the product wanted to tell you. A dossier assigned to you, an approval waiting, a processing failure.
The bell in the header shows unread ones; the screen shows all of them, and says You're all caught up when there is nothing.
It is a personal inbox, not an organisation-wide feed. It shows what concerns you. If somebody says "I never saw it", the question is usually whether they were on the case at all — chapter 13, dossier membership — rather than whether the notification was sent.
Support
Settings → Support files a request from inside the product: a description, and up to a small number of attachments — screenshots or documents that show the problem.
The prompt asks for the right thing: tell us what you expected and what happened instead. Two sentences in that shape are worth more than a paragraph of narrative.
There is one behaviour worth reading before you need it. If the message reaches us but does not get a ticket number, the screen says so and gives you a reference:
Your message reached us, but it did not get a ticket number, so a reply may take longer than usual. If it is urgent, write to support@dokgenius.com and quote the reference below.
Copy that reference. It is the screen telling you honestly that half of something failed, rather than showing a success and losing your request quietly — which is what most support forms do in that situation.
What you should have now
- Opened one audit event and followed its correlated events, so you have seen what an action really is.
- Read the retention line, and know how far back your trail actually goes.
- Understood that the count under a local filter is the unfiltered total.
- Your team told that the password change is on Account, not on the Security entry of the menu.