Auditor read-only mode

The auditor role exists for one job: observe the workspace without changing it. Compliance officers, internal auditors, external consultants, regulators — anyone who needs visibility without write access.

What auditors see

Everything a super_admin sees, with one difference: every write action is disabled.

What auditors can do

The few write actions:

• Filter the audit log — apply filters, export to Excel
• Filter the user list — apply filters
• Search and sort — across every page
• Open every detail panel
• Read every comment, every rejection thread, every audit entry

If a workflow has been configured to use auditor as an approver role at a specific step, the auditor CAN approve / reject at that step. This is the one explicit override of the read-only stance — it has to be deliberate, and the workflow builder shows a warning when you configure it (see Workflow builder).

Why this role exists

Three customer-driven reasons:

1. Regulatory inspections

When a regulator inspects your training programme, they need to verify:

• Who completed what training, when
• Who approved what content, when
• What the content actually was at the time of approval
• That no shortcuts (e.g. one person being trainer + content_manager + super_admin) circumvented the chain of review

An auditor account gives the regulator their own login with permissions that match their job. They don’t get a super_admin’s keys; they get visibility.

2. Internal audits

Most organisations have an internal audit function that periodically reviews L&D for compliance. An auditor account lets them do their work without involving the super_admin in every search and click.

3. Compliance evidence for SOC 2 / ISO

For organisations going through SOC 2 Type II or ISO certification, an auditor account is one way to demonstrate that:

• The audit log is being reviewed
• A separation-of-duties model is enforced
• Compliance access doesn’t require workspace write access

Setting up an auditor

A super_admin creates the auditor account via the Users page — same flow as any other user, just pick auditor as the role. The auditor gets a welcome email, sets their password, signs in.

For an external auditor (e.g. a regulator), you can create a temporary account that you deactivate after the inspection. Deactivation preserves their login history in the audit log but blocks future access.

Department-scoped auditors (roadmap)

Currently, auditors see the entire workspace. A roadmap item is department-scoped auditors — for organisations where auditors should only see their assigned departments.

If this matters to you, tell us. It hasn’t shipped yet because no customer has needed it.

Auditor as approver (the exception)

If you configure a workflow step with role auditor, the auditor for that step CAN take action — approve or reject. This is the one carve-out to the read-only stance.

Why this exists: Compliance Triple Sign-off workflows often want the auditor as the formal compliance check. The auditor sees the same review UI as a content_manager, decides, and the decision is recorded.

This is intentional. Don’t configure it accidentally — the workflow builder shows a warning when you pick auditor as an approver role.

Audit trail of the auditor

Every page view, every export, every filter applied by the auditor is recorded in the audit log. The actor is the auditor; the resource is whatever they viewed.

This is by design: auditors of the audit log are also auditable. Compliance customers asked for this; it closes the trust loop.

What auditors can’t see

The two genuine gaps:

• Learner-side learner sessions — auditors can see learner completion data via Analytics, but not the learner’s actual session (which card they were on at 3pm Tuesday). Same as every other admin role.
• Encrypted token values — integration credentials are encrypted at rest. Auditors see the integration connection status but never the raw token. Same as super_admins.

If auditors need either of these, talk to us — we can think about what could be exposed safely.