> For the complete documentation index, see [llms.txt](https://docs.notionapps.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.notionapps.com/users/identity-admin.md).

# Identity admin

Canonical page for identity **dual-write**: `role_field_id`, `active_field_id`, and `profile_field_ids`. The existing identity-admin how-to is closer to the verbose bar than most Users pages; this file is the public canonical expansion. Do not create “Identity 2.”

## What this is / when to use it

Identity keeps the **Users database** and the **login identity** in agreement. Dual-write means when a user signs up, is invited, or is deactivated, NotionApps writes the same facts onto the Users row.

| Field id            | Meaning                                                                                                         |
| ------------------- | --------------------------------------------------------------------------------------------------------------- |
| `role_field_id`     | Which Users property stores the app role (Client, Staff, Approver). Navigation and screen visibility read this. |
| `active_field_id`   | Which property means “this login may enter.” Inactive users fail login even if they still exist.                |
| `profile_field_ids` | Extra Users properties treated as profile (name, locale, phone). Profile screen and some prefs read these.      |

Use dual-write when roles and active flags must stay true in Notion, not only in a hidden identity table.

When **not** to: a public app with no users.

## Before you start

1. Users database exists and is synced.
2. You have a Role property (select or text) and an Active property (checkbox or select).
3. You understand [data restriction](https://docs.notionapps.com/databases/data-restriction-and-filters) uses these rows too.

## Build it

1. Open **Users → Identity** (or Identity admin).
2. Map **Role** to `role_field_id`.
3. Map **Active** to `active_field_id`.
4. Add profile properties to `profile_field_ids` (Display name, Language).
5. Set signup defaults so new rows get Role + Active. See [Sign up](https://docs.notionapps.com/users/sign-up).
6. Invite one staff user. Confirm the Notion row shows Role and Active.
7. Deactivate from the app users list. Confirm Active flips and login is denied.

## Every control

| Control          | What it does                                                                                     |
| ---------------- | ------------------------------------------------------------------------------------------------ |
| Role field       | Dual-write + role menus.                                                                         |
| Active field     | Dual-write + login gate.                                                                         |
| Profile fields   | Dual-write + Profile screen.                                                                     |
| Provision source | How the identity was created (invite, signup, admin). Read-only diagnostics.                     |
| View as          | Impersonate for testing. [View as any user](https://docs.notionapps.com/users/view-as-any-user). |

Password reset (end user and maker) is not a second identity product:

* **End user** — login screen “Forgot password” for Email & password. OTP users request a new code.
* **Maker** — NotionApps account password reset on the builder login, not inside the app.

## What users see

They see a role-appropriate nav and a Profile screen. They do not see field ids. If they are inactive, they see a login error.

## Limits and plans

* Identity admin for **platform operators** (locks, cross-account) is out of scope for public docs.
* Changing `role_field_id` after users exist does not rewrite history. Backfill Notion, then sync.
* Localization (15+ UI languages) can be a profile field plus the app language picker. See [Profile](https://docs.notionapps.com/screens-and-components/types-of-screens/everyday-chrome-screens/profile).

## Example

Users database: Email, Name, Role (Client/Staff/Approver), Active (checkbox), Company (relation). Map Role, Active, Name. Signup default Role=Client, Active=true. Staff added by invite with Role=Staff.

## Fix problems

| Symptom                       | Likely cause                        | What to do                 |
| ----------------------------- | ----------------------------------- | -------------------------- |
| Nav wrong                     | Role field not mapped or not synced | Map `role_field_id`. Sync. |
| Deactivated user still enters | Active not mapped                   | Map `active_field_id`.     |
| Profile empty                 | Profile field ids empty             | Add them.                  |

## Related

[Sign up](https://docs.notionapps.com/users/sign-up). [Roles and navigation](https://docs.notionapps.com/users/roles-and-navigation). [App Users](https://docs.notionapps.com/users/app-users).