Governance

Set retention policies and run the purge, place legal holds, and classify sensitive fields so only the right people can read them.

Governance is where you decide how long records are kept, stop deletion when a dispute means nothing may go, and control who may read sensitive fields. It also lists the third-party applications authorized against your organization. Nothing here deletes or hides anything until you configure it.

Opening Governance#

Choose Governance in the sidebar. It has four tabs: Retention, Legal holds, Classification and Applications. The first three need data_governance.view; Applications needs oauth_application.view and is described in OAuth applications.

Permissions

data_governance.viewdata_governance.manageoauth_application.view

data_governance.view lets you read policies, holds and classifications. data_governance.manage lets you create and change them and run the purge. Organization Owner and Organization Admin hold both.

Retention policies#

A retention policy says how many days one kind of record is kept before it becomes eligible for deletion. UnitX ships no default retention period for anything: the right number depends on your business, so every policy is a value you chose deliberately.

Record types you can set a policy for#

Audit records: The organization’s permanent record of changes.
Activity feed: The team-facing history of records, as distinct from the audit trail.
Notifications: In-app notifications past their window.
Delivered events: Events that have already been delivered to notifications, email and so on.
Project reality history: Stored snapshots behind Project reality.
Security events: Sign-ins, credential and permission changes. Never removed unless you configure a policy for this type explicitly.

Create a policy#

Choose a record type
On the Retention tab, pick one from Record type. Only types UnitX can actually purge, and that do not already have a policy, are offered.
Set Retention days
At least 1. There is no suggested value — pick one you can defend.
Add a description
Optional, but useful: say why this number was chosen.
Choose Create policy
The policy appears in the list with Never run until the purge first runs.

To change a policy, edit its Retention days or Description and choose Save. There is one policy per record type, and a policy cannot be deleted — only edited — so “why was this deleted?” always has an answer.

Preview and run the purge#

Choose Preview what would be removed
This counts, per record type, what is past its window. It deletes nothing.
Read the report
Each line shows how many records are past their window and how many a legal hold would keep, or why a type was skipped.
Choose Run purge now
Every policy is applied. Records under a legal hold are left in place, and each policy shows when it last ran and how many records it removed.

Warning

A purge permanently deletes records. Always preview first — the preview and the real run use the same rules, so what the preview counts is what would go.

Legal holds#

A legal hold says a particular record must not be deleted, whatever its retention policy says. A hold always wins over a retention window.

Open Legal holds
Go to GovernanceLegal holds.
Point at the record
Enter the Entity type (for example work_item) and the Entity id of the record to protect. A hold can point at any kind of record, including ones that have no screen of their own.
Give a reason
Reason is required — name the matter or request behind the hold.
Choose Place hold
The hold appears as Active, with who placed it and when.

A record can have only one active hold. Placing a second on the same record returns an error rather than stacking.
To stop every deletion in the organization — for example during litigation — place a hold whose entity type is organization and whose entity id is your organization’s id. Every purge then reports that it was skipped because the organization is under legal hold.
Release hold ends a hold. Released holds stay in the list as Released, with who released them and when.

Data classification#

Some fields need narrower access than the record they sit on: a line manager may need the member list but not everyone’s email address; a payroll team may need pay details that nobody else should see. Classification lets you label a field’s sensitivity and, if you choose, hide it from people without a particular permission.

Every organization starts with a list of fields UnitX knows to be sensitive, each marked platform default. By default every field is readable by anyone who can see the record, so nothing is taken away until you set a reader requirement. The badge at the top shows how many fields are currently restricted to a permission; the record type filter narrows the list.

Level: Public, Internal, Confidential or Restricted. On its own a level is a label: it records how sensitive the field is and hides nothing.
Readable by: Everyone who can see the record, or Holders of a permission you choose. Only this setting actually hides a field.
Reset: Returns a field you changed to the UnitX default level and reader setting.

Hide a field from most people#

Find the field
Open GovernanceClassification and filter by record type if needed.
Set its level
For example, set organization_member.user.email to Confidential.
Set Readable by
Choose Holders of member.manage_roles. The member list still works for everyone; only people who manage members see addresses.

Note

Choosing Everyone who can see the record for a field you changed returns that field to its UnitX default, the same as Reset.

People without the permission still get the record — the field is simply not in it, and screens say so (for example Email hidden by your organization’s policy) so a hidden value is never mistaken for an empty one. Reading a Restricted field that has a reader requirement is recorded in the audit trail with the field names and number of records, never the values.

Applications#

The fourth tab lists the OAuth applications registered against your organization and lets you register or revoke them. See OAuth applications.

Why is the security log treated differently?

Sign-ins, credential changes and permission changes are the record of what happened to an account. A purge never removes them as a side effect; configure Security events explicitly if you want a window for them.

Is a purge itself recorded?

Yes. Every purge that removes anything writes an audit record with the record type, the window, the cut-off, how many were removed and how many a hold kept.

Does Restricted hide a field on its own?

No. The level is a label. Only a Readable by requirement hides a field.

Can I delete a retention policy?

No, only edit it.

Still stuck? Search the docs with ⌘K, open Help inside UnitX, or contact support.