> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getcollate.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Breaking Changes - Data Governance | Official Documentation

> New task-based policy operations, PII recognizer accuracy fixes, faster-firing governance workflows, and Policy Agent defaults backfilled onto existing services in Collate 2.0.

# Data Governance

Most of what changes here is downstream of the Task redesign: policies, workflows, and the new
Data Access Request / Policy Agent feature are all task-shaped in 2.0. A PII recognizer fix and a
governance-workflow timing change are the two items worth planning around independently.

## New task operations are not backfilled onto custom policies

**Behavioural.** Affects custom policies, non-admin users and bots.

`resourceDescriptor` gains five new task operations: `CreateTask`, `EditTask`, `ResolveTask`,
`CloseTask` and `ReassignTask`. The migration seeds a new `TaskAuthorPolicy`, attaches it to the
`DataConsumer` role, and adds task rules to `DataConsumerPolicy` and `ApplicationBotPolicy` — but
seed policies are **create-if-not-exists**.

<Warning>
  If you replaced `DataConsumerPolicy` or `ApplicationBotPolicy` with your own definition, the
  migration does **not** backfill the new task operations onto it. Non-admin users and application
  bots will receive `403` when creating or editing tasks until you add a rule like:

  ```json theme={null}
  {
    "name": "DataConsumerPolicy-CreateTask-Rule",
    "resources": ["task"],
    "operations": ["Create"],
    "effect": "allow"
  }
  ```
</Warning>

Task authorization is also self-approval guarded — a task's creator cannot approve their own task,
even where policy would otherwise allow it. Approval automation that submitted and approved with the
same service account must be split across two principals, or use
`emptyAssigneeStrategy: assignAdmins`. Separately, the reviewer-authorization shortcut that let a
reviewer create an entity without an explicit grant is removed (**behavioural**): flows relying on it
now need an explicit `Create` grant.

## A PII recognizer fix changes existing tags

**Behavioural.** Existing tags might be wrong; new runs will differ.

The CVV recognizer's regular expression is anchored by the migration, from `\b\d{3,4}\b` to
`\A\d{3,4}\Z`. The unanchored pattern matched the `125` inside values like `SCN-125`, so any column
whose name carried a CVV context word (`code`, `card`, `cvv`) and whose values contained a 3–4 digit
run was tagged `PII.Sensitive` — for example `scenario_code` or `error_code` — because the context
boost set the score straight to the maximum, turning a low-confidence pattern into a certain match.

<Tip>
  Review existing `PII.Sensitive` tags on columns named `*_code`. The migration fixes the recognizer
  going forward; it doesn't retract tags already applied.
</Tip>

Related fixes: overly broad context keywords are removed from PII recognizers, sibling-tag score
ties are now broken by column-name match, and temporal table period columns are excluded from
auto-classification sampling. Separately, auto-classification now extends to topics and storage
containers (**additive**) — expect new tags to appear on messaging and storage assets, and widen any
PII-tag-keyed policy or alert coverage accordingly.

## Governance workflows fire far sooner

**Behavioural.** Affects every governance workflow, and raises steady-state database polling.

The migration lowers three intervals on **existing** deployments:

| Setting                              | 1.13      | 2.0          |
| ------------------------------------ | --------- | ------------ |
| `WorkflowEventConsumer.pollInterval` | 10 s      | **1 s**      |
| `asyncJobAcquisitionInterval`        | 10,000 ms | **1,000 ms** |
| `timerJobAcquisitionInterval`        | 60,000 ms | **5,000 ms** |

Approval tasks now appear near-instantly after the triggering change instead of up to 10 seconds (or,
under load, minutes) later. On very large clusters, monitor database load after the upgrade and raise
the intervals if needed.

<Note>
  Workflow migrations run inside a guard: a workflow-handler failure logs and continues rather than
  aborting the rest of the data migration. If you see *"Failed to initialize WorkflowHandler … in
  v200"* in the upgrade logs, restart the server to complete workflow wiring.
</Note>

The `userApprovalTask` node also gains task-lifecycle configuration (additive, backwards compatible):
an `assignees.emptyAssigneeStrategy` of `assignAdmins` falls back to all platform admins, excluding
the requester, instead of the 1.13-matching default of auto-approving or leaving the task unassigned.
Set it explicitly on approval nodes where unassigned tasks were silently auto-approving.

## Policy Agent defaults are backfilled onto existing services

**Behavioural.** Affects existing Snowflake, Databricks, and Unity Catalog services.

Collate 2.0 introduces self-service Data Access Requests backed by a Policy Agent that executes
grants and revokes against the source system. Because schema-level defaults only apply at
create-time deserialization, the migration rewrites **stored rows** for existing services:

| Service type  | `enabled` | `supportsFullAccess` | `supportsMaskedAccess` | `supportsColumnAccess` |
| ------------- | --------- | -------------------- | ---------------------- | ---------------------- |
| Snowflake     | `true`    | `true`               | `true`                 | `false`                |
| Databricks    | `true`    | `true`               | `false`                | `false`                |
| Unity Catalog | `true`    | `true`               | `false`                | `false`                |

Operator-set `true` values are preserved; only `false` or missing values change. `policyAgentConfig`
is **removed** from the Postgres schema and stripped from stored rows entirely.

<Warning>
  After the upgrade, the Request Access affordance appears on Snowflake, Databricks, and Unity Catalog
  assets, and disappears from Postgres. Set `enabled: false` explicitly on services where you don't
  want Data Access Requests available.
</Warning>

## Glossaries gain native OWL/RDF ontology import

**Additive.**

```
PUT /v1/glossaries/name/{name}/importRdf
```

Imports an OWL/RDF ontology into a glossary, preserving identity for round-trips. Two new fields
support this:

| Entity         | Field          | Purpose                                                                                |
| -------------- | -------------- | -------------------------------------------------------------------------------------- |
| `glossaryTerm` | `iri`          | Canonical IRI of the term in its source ontology, used as the RDF subject when present |
| `glossary`     | `namespaces[]` | Prefix-to-namespace IRI mappings, so CURIEs render and re-export preserves identity    |

<Note>
  A glossary term created in the UI has no `iri`. Terms imported from an ontology carry one, and export
  re-emits it. Do not rewrite `iri` on update, or you'll break round-trip identity.
</Note>

Relation types also gain OWL property characteristics used for RDF round-trip and optional
validation (not enforced by default): `domain[]`/`range[]` (term names or class IRIs a source/target
term must be typed as), `isFunctional`/`isInverseFunctional`, and
`isReflexive`/`isIrreflexive`/`isAsymmetric`. Relation types are readable by any authenticated user
and paginated, all relation types between the same term pair are preserved, and glossary rename now
cascades to child terms in the search index.

## Domains, data products, and intake forms round out the release

**Additive.** No breaking changes in this area for 1.13 → 2.0.

* An ODPS data product schema (`entity/domains/odps/odpsDataProduct.json`), Data Product support in
  the Observability UI, a certification quick filter on the Data Products listing, and a
  request-access button for data products.
* A new `assignedTo` relationship type, and domain-scoped activity-feed visibility (task domains are
  backfilled by the migration).
* `governance/intakeForm.json` and `POST /v1/governance/intakeForms` add structured intake forms,
  used with `taskFormSchema` to drive request and approval workflows with typed inputs.

## Collate AI agent types are removed from the governance schema

**Breaking.** The `agentType` enum drops `CollateAI`, `CollateAITierAgent` and
`CollateAIQualityAgent` — only `Metadata` remains — and their configuration schemas are deleted. See
[AI Agents & Automations](/ai-2-0/release-2.0/breaking-changes/ai-agents-and-automations) for the full
migration. Remove references to these agent types from application configuration and any automation
filtering ingestion pipelines by `agentType`; use the new filter values `metadata` and `application`
on `GET /v1/services/ingestionPipelines` instead.

## Full detail

For the full narrative walkthrough of Data Governance in Collate 2.0 — including screenshots and step-by-step context — see [Release 2.0: Data Governance](/ai-2-0/release-2.0/data-governance).