> 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/consent/consent-and-it-policy/consent-reference.md). # Consent data model and audit actions The four consent tables and their columns, the screens that write them, the audit action each operation records, and the deprecated single-policy path. ## What this covers These tables support [Consent and IT policy](/administration-guide/consent/consent-and-it-policy.md). Read that page to publish a policy; come here to query the acceptance history, report over it, or work out why an audit search returns nothing. Release boundaries matter more here than on most features, because a system upgraded through `4.2.1.6` carries rows written before versioning existed; those are flagged. ## The data model | Table | Key columns | Notes | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `IT_POLICY` | `IT_POLICY_ID`, `NAME` (64), `DESCRIPTION` (512), `APPROVE_TYPE` (64), `ACTIVE`, `EFFECTIVE_DATE`, `CREATED_BY`, `UPDATED_BY`, `POLICY_CONTENT` (LONGTEXT), `CONFIRMATION` | `NAME`, `DESCRIPTION` and `EFFECTIVE_DATE` exist as of `4.2.1.6`. `POLICY_CONTENT` and `CONFIRMATION` are the pre-`4.2.1.6` single-text columns, still present but superseded by versions — text you find there is not what a user is shown | | `IT_POLICY_VERSION` | `VERSION_ID`, `NAME`, `VERSION_NUMBER`, `IT_POLICY_ID`, `ACTIVE`, `CREATE_DATE`, `UPDATE_DATE`, `CREATED_BY`, `UPDATED_BY` | Many per policy; the runtime picks the first with `ACTIVE='Y'` | | `IT_POLICY_VERSION_LANG_MAP` | `ID`, `VERSION_ID`, `LANGUAGE_ID`, `CONSENT` (LONGTEXT), `CONSENT_CONFIRMATION` (LONGTEXT) | One row per language per version. This is **not** `LANGUAGE_MAPPING` — consent text has its own table | | `USER_IT_POLICY_HISTORY` | `ID`, `USER_ID`, `VERSION_ID`, `CONTENT_PROVIDER_ID`, `SUBMIT_DATE`, `ACCEPTED`, `NAME` (128) | The evidence row. `CONTENT_PROVIDER_ID` and `NAME` both exist as of `4.2.1.6`, so rows written before that upgrade record neither | | `CONTENT_PROVIDER.IT_POLICY_ID` | FK to `IT_POLICY` | Exists as of `4.2.1.6`. This single nullable column is the whole enforcement wiring | | `USERS.DATE_IT_POLICY_APPROVED` | timestamp | The pre-versioning record, present since `3.0.0.6`. Still written and read by the deprecated `/usePolicy` page only | OpenIAM will not let a history row be re-pointed at a different user or version once it is written: both join columns are fixed at insert. That is deliberate — the row is evidence, and the only supported way to withdraw it is the revocation path below, which leaves its own audit trail. ## The screens, and what each one records Webconsole: | Screen | Route | Audit action | | ---------------------------------------------------- | ---------------------------------------------- | ------------------------------------------------------- | | Consent configurations (search) | `/webconsole/it-policy` | — | | Edit one policy — creating or changing it | `/webconsole/it-policy-edit?id=` | `IT_POLICY_ADD` on create, `IT_POLICY_MODIFY` on update | | Delete a policy from that screen | `/webconsole/it-policy-edit?id=` | `IT_POLICY_DELETE` | | A user's consent history, and revoking one row of it | `/webconsole/it-policy-history` | `USER_IT_POLICY_HISTORY_RESET` | The search menu resource is `CONF_POLICY_PAGE`, whose English `LANGUAGE_MAPPING` text was rewritten to **Consent configurations** as of `4.2.1.6`; before that release the menu read differently and pointed at `/webconsole/configurePolicy.html`, so an older runbook naming that URL is out of date. The history menu is `USER_IT_POLICY_HISTORY`, display order 15 under `USER_EDIT_MENU`, labelled **Consent history**. SelfService and the IdP, which is where the user meets consent: | Screen | Route | Audit action | | --------------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------ | | The acknowledgement page, in the user's current language | `//it-policy-use` | `IT_POLICY_SUBMIT`, then overwritten with `CONFIRM_IT_POLICY` or `DECLINE_IT_POLICY` | | The user's own history, and revoking their own acceptance | `/selfservice/it-policy-history` | `IT_POLICY_RESET_BY_USER` | `` is `selfservice`, `selfservice-v2` or `idp`. Opening a history row on either screen shows the text that was accepted. A user attempting to revoke a history row that is not their own is refused with `IT_POLICY_RESET_BY_USER_FORBIDDEN`; administrator revocation is the Webconsole screen above, and it records the requestor and the target user both. There is no screen that resets the legacy single policy described below. That path is deprecated and audits `RESET_IT_POLICY`; if you need it undone on an upgraded system, that is a support request. ## The deprecated single-policy path The pre-`4.2.2` page at `//usePolicy` still exists and is deprecated as of `4.2.2`. It shows a *single* legacy policy, writes `USERS.DATE_IT_POLICY_APPROVED` when the user acknowledges it, and creates **no** `USER_IT_POLICY_HISTORY` row. Do not use it, and do not read `DATE_IT_POLICY_APPROVED` as evidence on a current installation: a user who acknowledged through that page has a timestamp and no history row, which will read as "never accepted" on every screen and report in this guide. The legacy page also understands only `ANNUALLY` and `ONCE`, which produces an endless acknowledgement loop on a `SEMIANNUALLY` policy — see [Renewal](/administration-guide/consent/consent-and-it-policy.md#renewal-the-three-values-and-what-they-compute). The reset for that single legacy policy, audited `RESET_IT_POLICY`, is deprecated with it and has no screen. ## The audit actions All of these live under the `IT_POLICY` audit target. Retention properties exist for each and all ship `-1`; see [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md). | Action | Written when | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | `IT_POLICY_ADD` | A save creates a policy | | `IT_POLICY_MODIFY` | A save updates one | | `IT_POLICY_DELETE` | The policy is deleted. A failure records `IT_POLICY_NOT_FOUND` and *"Consent with ID `` was not found"* | | `IT_POLICY_SUBMIT` | The user submitted the acknowledgement page. Normally overwritten by one of the next two, so seeing it alone means the submission failed before the branch | | `CONFIRM_IT_POLICY` | A user accepted. Description reads *"User `` with id = `` accepted IT policy"* | | `DECLINE_IT_POLICY` | A user declined and was redirected to logout | | `IT_POLICY_RESET_BY_USER` | Self-revocation. A failure with `IT_POLICY_RESET_BY_USER_FORBIDDEN` means somebody tried to revoke another user's row | | `USER_IT_POLICY_HISTORY_RESET` | Administrator revocation, with requestor and target user both recorded | | `RESET_IT_POLICY` | The deprecated single-policy reset | **`SAVE_IT_POLICY` exists as an action name but is never what a save records**, so an audit search on it returns nothing. Search for `IT_POLICY_ADD` and `IT_POLICY_MODIFY` instead. ## Related * [Consent and IT policy](/administration-guide/consent/consent-and-it-policy.md) — publishing a policy, versioning it and gating a content provider * [Content providers and URI patterns](/administration-guide/access/content-providers-and-uri-patterns.md) — the object that carries `IT_POLICY_ID` * [Enumerated value reference](/administration-guide/reference/enums.md#consent-renewal-frequency) — the three `ITPolicyApproveType` values * [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md) — the retention key behind each action above *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/consent/consent-and-it-policy/consent-reference.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.