> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/platform/analytics-dashboard.md). # Configure an analytics dashboard tile Add, correct or retire a counter tile on the analytics dashboard, and read the six shipped tiles literally enough to trust the numbers. ## What this is, and when you need it The analytics dashboard is a row of counters over the audit log. Each tile names a set of audit actions and shows how many matched in the window you selected; clicking it lists the events. Come here to add a tile, to correct one whose number nobody believes, or to find out what an inherited tile is actually counting — which is rarely what its name suggests. A tile is a convenience, not a control. Nothing versions a tile definition, and the counts inherit every property of the audit log they query. ## At a glance | | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **You will end up with** | A tile on the dashboard whose count you have reconciled against an audit search for the same actions and window | | **Where** | **Administration → Analytics dashboard configuration** at `/webconsole/analytics-dashboard/configuration`; the dashboard itself is the **dashboard** icon in the Webconsole header bar, at `/webconsole/analytics-dashboard/summary` | | **You need first** | The exact audit action names you want counted — from [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md) — and a display order that does not collide with an existing tile | | **Takes** | 10 minutes per tile, plus one reconciliation against an audit search | | **Reversible** | Yes — a tile can be deactivated or deleted, and nothing else changes. The audit history it counted is untouched | ## Add or change a tile {% stepper %} {% step %} ### Open the Analytics dashboard configuration screen Go to **Administration** → **Analytics dashboard configuration**. **Analytics Dashboard Configurations** lists every tile with **Name**, **Type**, **Active** and **Description**, and can be filtered by name or type. {% endstep %} {% step %} ### Click Create Tile, or open an existing tile Editing lands you on **Edit Tile** at `/webconsole/analytics-dashboard/configuration-edit?id=`. {% endstep %} {% step %} ### Choose Type Three types ship, and the choice decides which of the other fields is honoured and what the detail view shows. | Type | Label on screen | Detail view is about | Managed-system scope | | ----------------- | ------------------ | ------------------------------------------------------ | ---------------------- | | `GENERIC_AUDIT` | Generic Audit | The user the event names | Stored and **ignored** | | `REQUEST_AUDIT` | Request Audit | The requestor | Stored and **ignored** | | `PROVISION_AUDIT` | Provisioning Audit | The target user, managed system and connector response | **Applied** | Type cannot be blank; the form rejects it with *"Type is required"*. {% endstep %} {% step %} ### Set Name, Description and Display Order **Name** is capped at 64 characters and must be unique — a duplicate is rejected with *"Tile already exists"*. **Display Order** is required and is the only thing deciding left-to-right position; the shipped tiles occupy 1 to 6. {% endstep %} {% step %} ### Name the audit actions, or the request types For a `GENERIC_AUDIT` or `PROVISION_AUDIT` tile, list the actions in **Audit Actions**. They are matched exactly, so `LOGIN` does not include `LOGIN_VIA_SOCIAL`. At least one is required: *"Audit actions are required"*. For a `REQUEST_AUDIT` tile, use **Activiti Requests** instead and let the actions be derived. On save OpenIAM *replaces* the action list with five actions per request type you chose — that request's initiate, notify, complete, accept and reject actions — and discards anything you typed into **Audit Actions**. Do not hand-edit both. {% endstep %} {% step %} ### For a Provisioning Audit tile, choose the managed systems The form carries a required-field message for this list, *"Managed system is required"*. This is the only type where the list reaches the count — see [The shipped Provisioning tile is scoped to OpenIAM itself](#the-shipped-provisioning-tile-is-scoped-to-openiam-itself). {% endstep %} {% step %} ### Set Active, then save **Active** is what puts the tile on the dashboard: the summary loads active tiles only, and the stored default is inactive. Save reports *"Tile saved"*, then redirects the browser to `tile-edit?id=…`, which is not a route this product serves, so you land on an error. **The tile is saved.** Go to `/webconsole/analytics-dashboard/configuration-edit?id=` instead, or back to the list. {% endstep %} {% step %} ### Reopen the tile and read the action list it actually kept The step people skip, and the only way to see what a `REQUEST_AUDIT` tile derived from your request types. {% endstep %} {% endstepper %} ## The six tiles that ship, and exactly what each counts All six ship active as of 4.2.2.0, so a fresh installation shows all six. | Tile | Type | Audit actions counted | | ---------------- | ------------------ | -------------------------------------------- | | Authentications | Generic Audit | `AUTHORIZE`, `LOGIN` | | Password changes | Generic Audit | `CHANGE_PASSWORD` | | Joiners | Generic Audit | `CREATE_USER` | | Terminations | Generic Audit | `USER_TERMINATE` | | Access requests | Request Audit | `CREATE_USER_REQUEST` | | Provisioning | Provisioning Audit | `PROVISIONING`, scoped to managed system `0` | Read those lists literally before you quote a number to anybody. * **Authentications** counts `LOGIN` and the OAuth `AUTHORIZE`, and nothing else. Not `LOGIN_VIA_SOCIAL`, not `LOGIN_PKS12`, not `DO_LOGIN_AGAINST_MANAGED_SYSTEM`. * **Terminations** counts `USER_TERMINATE` but not `AUTOMATIC_USER_TERMINATION` or `TERMINATE_USERS_BY_LAST_DATE`, so a scheduled termination sweep does not appear on it. * **Access requests** counts `CREATE_USER_REQUEST`, which is **not an audit action this product writes**. A new-hire-with-approval request writes `CREATE_USER_REQUEST_INIT`, `_NOTIFY`, `_COMPLETE`, `_ACCEPT` and `_REJECT`. The shipped tile therefore reads zero however much request traffic you have. Repair it by opening the tile, choosing the request types you care about under **Activiti Requests**, and letting the actions be derived. The full catalogue is [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md). ### One limit on Request Audit tiles Most request types share one generic action set: **Add User To Role**, **Remove User From Role**, **Add User To Group**, **Edit User** and a dozen more all derive `CREATE_GENERIC_REQUEST_INIT` through `CREATE_GENERIC_REQUEST_REJECT`, so two tiles built from two of them count the same events and show the same number. Only the request types with actions of their own — new hire with approval, new hire without approval, self-registration, position change, revoke access, terminate user — separate this way. ### The shipped Provisioning tile is scoped to OpenIAM itself The shipped **Provisioning** tile carries one managed system: `0`, named `OPENIAM`, the internal identity repository. Provisioning events to a managed system record *that* system, so a tile scoped to `0` does not count them. To see provisioning to Active Directory, open the tile and add the Active Directory managed system — then confirm the effect against the detail view rather than assuming it, because the count and the detail view take their managed-system filter from different places. On a `GENERIC_AUDIT` or `REQUEST_AUDIT` tile the list is stored, shown again when you reopen the tile, and never applied. Do not use it to narrow one of those. ## Verification | What to check | How | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The tile was created or changed | `ANALYTICS_DASHBOARD_TILE_ADD` on create, `ANALYTICS_DASHBOARD_TILE_MODIFY` on update, `ANALYTICS_DASHBOARD_TILE_DELETE` on delete, with the submitted tile definition stamped onto the event | | It kept the actions you meant | Reopen the tile and read **Audit Actions** back — mandatory on a `REQUEST_AUDIT` tile, where the list is derived | | The number is right | Search the audit log for the same action set and window and compare totals. If they differ, the tile's action list and your search are not the same set | | It appears where you meant | Open the dashboard from the **dashboard** icon in the header bar and confirm the position matches **Display Order** | Because nothing versions a tile, that audit event is the only record of what a tile counted at a point in time. To find out what a number on last quarter's screenshot was measuring, read the `ANALYTICS_DASHBOARD_TILE_MODIFY` event. ## When it goes wrong | Symptom | Inspect | Fix | | --------------------------------------------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Saving lands on a page that does not exist | The URL in the address bar | The save succeeds and then redirects to `tile-edit?id=…`, which is not a served route. Go to `/webconsole/analytics-dashboard/configuration-edit?id=` | | A tile shows zero for a period you know had activity | The tile's action list, then whether those action names are ones the product writes | The list is matched exactly. `CREATE_USER_REQUEST` on the shipped **Access requests** tile is not written at all | | A tile still shows zero after the actions are right | The `auditlog` search index | Tile counts are audit searches, so a stale index under-reports. See [Search indexes](/administration-guide/reference/search-indexes.md) | | A long window shows less history than you expect | Whether audit pruning was ever enabled | Every `org.openiam.audit.log.prune.days.*` property ships `-1` and prunes nothing; a positive value silently removes the history behind the window. Read the current values under **Administration → System Configuration → System Audit Log** | | A Request Audit tile's actions change every time you save | **Activiti Requests** on that tile | For that type the action list is derived from the request types and overwrites what you typed | | A new tile is not on the dashboard | **Active** on the tile | A tile is created inactive. Only active tiles are loaded into the summary | | Two tiles show identical numbers | Their action lists | Two Request Audit tiles built from request types in the generic group count the same five actions | | Narrowing a tile to one managed system changed nothing | The tile's **Type** | The managed-system scope is applied on a Provisioning Audit tile only | | A tile cannot be created | The name | Names are unique and capped at 64 characters; a clash returns *"Tile already exists"* | ## Related * [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md) — every action name a tile can count, and the pruning properties behind the window * [Find audit evidence](/administration-guide/operations/find-audit-evidence.md) — the audit search you reconcile a tile count against * [Search indexes](/administration-guide/reference/search-indexes.md) — the `auditlog` index a tile reads, and how to tell it is stale *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/platform/analytics-dashboard.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.