Privacy override reason codes reference
This page lists the reason codes available when an admin applies privacy defaults retroactively to existing members.
A reason code is required whenever you use the Apply to existing members option on the Privacy defaults page. The selected reason is stored with the update’s record. (v1.5, 2026-10-17: this said the reason is “recorded in the privacy audit log for each member affected”; the per-member audit rows don’t carry it.)
To use the retroactive apply option, see Set org-level privacy defaults and lock fields.
Reason codes
Section titled “Reason codes”| Reason code label | When to use it |
|---|---|
| Compliance investigation | A compliance review or an external legal or regulatory demand requires specific fields to be set to a particular visibility |
| Member request via support | A member asked the organization to update their visibility through a support channel rather than doing it themselves |
| Bulk default apply | A routine update to align existing members with new org-wide defaults |
| Org policy change | A change in the organization’s privacy policy requires updated field visibility for all members |
| Other | Any reason not covered by the options above |
These five are the only choices, in the order they appear on the Privacy defaults page. The list is fixed: it isn’t read from your organization’s reason codes, so rewording, reordering or adding a reason code elsewhere doesn’t change it. (v1.6, 2026-10-20: this listed six reasons, including “Legal or regulatory request”, as defaults that came from your organization’s own reason codes and could be empty; the page shows a fixed list of five.)
How reason codes appear in the audit log
Section titled “How reason codes appear in the audit log”When you apply defaults to existing members, each member whose settings change gets a row on their Privacy audit tab, marked as an admin override and recording the admin who ran it (actorAdminUserId). Undoing the update adds a row the same way for each member it changes. The reason code you selected is kept with the update itself, not on each member’s row.
(v1.5, 2026-10-17: this section said “In the current version the retroactive apply isn’t carried out, so it adds no rows”, and that once it runs each row would show the reason code label. The apply is now built; its per-member rows carry the admin, not the reason.) (v1.4: this read “When you run a retroactive apply, each affected member’s Privacy audit tab gains rows for that batch. Each row shows:” the admin’s ID and the reason code label.)
This makes it easy to identify which admin initiated each change, supporting compliance and member-trust requirements.