Reference
Dashboard
Every widget on the dashboard, what it counts, why it might not be there, and which page owns the work behind it.
The dashboard is a summary, not a workspace. Every widget is read-only and links to the page that owns the work — you review on the review queue, resolve flags on the flags queue, decide nominations on the awards page. Nothing on this page changes content.
The range selector
One control at the top governs the whole page: 7, 30 or 90 days. It lives in the URL
(?range=90), so a view you are looking at can be linked to a colleague and survives a refresh.
Two things deliberately ignore it:
- Publishing over time is always a 12-month history. It answers "how has our output moved across the year", which is not a question a 7-day window can answer.
- Deadlines — review dates, staleness dates, the publishing schedule — are absolute. "Overdue" is overdue regardless of which range you are looking at.
Why a section might not be there
Sections are not hidden by the browser; they are never sent. The database decides what you may see and withholds the rest, so a widget you cannot see also did not load its data. A missing section means one of two things:
- You don't hold the permission it needs. The permission per widget is listed below.
- Your agency hasn't switched the feature on. Recognition is the only whole section this applies to — it is absent entirely until an admin enables it in Settings → Recognition (opens the admin console).
Your work
What is waiting on you, personally. Everything else on the page is agency-wide.
| Widget | Shows | Needs |
|---|---|---|
| My reviews | Reviews assigned to you, urgent first then soonest due; the red number is how many are past due | content.edit |
| Awaiting my approval | Items needing a second signature that you have not given yet, oldest first | content.approve |
| Mentions & threads | Unresolved comments naming you, plus open threads on content you wrote or review. Its unread count is the bell's; All notifications opens the full list | content.edit |
| Nominations | Peer badge nominations waiting on a decision | badges.award and recognition switched on |
Awaiting my approval lists items in review and also published items whose changes are held until they have their approvals. It counts against the item's current version. Editing an item after it was approved bumps its version and invalidates the approvals recorded against the old one, so an item can reappear here after someone edits it. That is the sign-off rule working, not a glitch — see how two-person sign-off works.
Content health
Whether what operators are holding is current and signed for.
| Widget | Shows | Needs |
|---|---|---|
| Review SLA | In-review items: past due, due this week, and how many have no reviewer assigned | content.edit |
| Going stale | Published content past — or within 30 days of — its re-validation date | content.edit |
| Field reports | Open operator flags by reason, and the age of the oldest one | content.edit |
| Acknowledgment coverage | For each item requiring sign-off, the share of active members who signed the version operators have | content.publish |
| Publishing schedule | What is queued to go live in the next 14 days | content.publish |
The two clocks are not the same clock
Review SLA and Going stale look similar and answer different questions:
- Review SLA is a deadline for a person: this reviewer must finish by this date.
- Going stale is a deadline for the content: this published guidance stops being trustworthy on this date, based on your agency's re-validation interval for that content type.
They also apply at different stages — the SLA while an item is in review, staleness once it is published — so they are two cards, and one is no guide to the other. The stale interval comes from Settings → Review policy (opens the admin console), and the nightly overdue job reads the same setting — the dashboard and the queue cannot disagree.
Acknowledgment coverage counts versions, not people
Someone who acknowledged version 3 has not seen version 4. Coverage is measured against the version operators were given — the last one published or released — so releasing a change to an acknowledged document resets its coverage, which is the honest answer to "has everyone read the current procedure?". A change still held for release does not reset it, because no operator has it yet.
Recognition
Absent entirely unless recognition is switched on for your agency.
| Widget | Shows |
|---|---|
| Badges awarded | Awards in the range, with a trend line and the most-awarded badges |
| Level distribution | How many members sit on each rung of the ladder |
| Track progress | Per badge group: of the people who started the track, how many finished |
These are head-counts, never a ranking — no names, no ordering of individuals. That is why they appear whatever your leaderboard setting is: an agency that switched public ranking off did so to avoid exposing individuals, and a distribution exposes nobody. Named standings stay in Recognition (opens the admin console).
Revoked awards are excluded. A badge that can be re-earned counts each time it is earned.
Engagement
| Widget | Shows | Needs |
|---|---|---|
| Content by guide | Published leaf items per top-level guide, including items inside its sub-guides | — |
| Favorites | Favourites added in the range, against the previous range | — |
| Checklist activity | Checklist progress recorded in the range | — |
| Quiz performance | Attempts, pass rate, mean score, and the quizzes people fail most | content.edit |
| Read → complete | Reads against completions, overall and per content type | content.edit |
| Recently updated | The latest edits across the library | — |
| Most read | What operators actually opened in the range | — |
| Search insights | What people searched for — and what returned nothing | — |
The weakest quizzes list ignores quizzes with fewer than three attempts: one person's bad morning is not a content defect. A low pass rate is a signal about the material first — the link goes to that quiz's analytics so you can find the question everyone gets wrong.
Searched, found nothing is the highest-signal list on the page. Somebody needed that answer in the field and the library came up empty.
Operations
| Widget | Shows | Needs |
|---|---|---|
| Operator reach | Active in 7 and 28 days, the share reachable by push, and members who never opened the app | users.manage |
| Plan & usage | Seats, content and storage against your plan's caps, plus billing state | billing.manage |
Reachable by push is the number that matters before an urgent publish. An operator with no registered device gets no notification — the content reaches them only when they next open the app.
Plan & usage shows the caps the system will actually enforce. If your agency has a sponsored plan, or a paused subscription, the caps follow the plan that is genuinely in effect rather than the one on the invoice. Details in Billing (opens the admin console).
What updates live, and what doesn't
The four queue widgets under Your work, plus Review SLA, Going stale and Field reports, refresh by themselves when someone else acts — a review assigned in another window shows up here within a moment. The analytics do not: re-running a 90-day aggregate because somebody typed a comment costs more than it tells anyone. They refresh when you change the range or return to the page.
Nominations is the exception among the queues — it refreshes on navigation rather than live.
See also
- Get startedSet up your agencyThe path from an empty ROK tenant to operators reading vetted content on their phones — in the order that avoids rework.
- How it worksHow publishing worksThe path a piece of content takes from a blank draft to something an operator can read offline — and what the database will and won't let you skip.
- How it worksHow two-person sign-off worksWhy an item needs a second approval, when ROK refuses to let one person publish alone, why approvals expire when content changes, and how policies make the rule automatic.