For the complete documentation index, see llms.txt. This page is also available as Markdown.

🆔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 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.

  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.

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.

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.

Sign up. Roles and navigation. App Users.