App Users
App Users are people who may authenticate into a private published app. They come from the linked Users database and the Builder user-management flow. They are different from collaborators, who can edit and publish the app.
What makers can manage
Section titled “What makers can manage”- Add a named user while public signup stays off.
- Assign a role during creation when roles are configured.
- Send and resend password invitations.
- See setup, provisioning, expiration, and password-established status.
- Send password-reset emails.
- Disable and re-enable access.
- Inspect how the identity was provisioned.
- Use user properties for Data Restriction, navigation, and personalization.
Read the user row
Section titled “Read the user row”A user has two connected parts:
- The Users-database row stores profile and authorization fields such as Name, Email, Role, Active, Company, or Language.
- The app identity stores login providers and password lifecycle state.
NotionApps reconciles these parts during controlled provisioning and sync. A row is not proof that password setup is complete; use the Access state.
Access states
Section titled “Access states”| State | Meaning |
|---|---|
| Not invited | The row exists but no usable setup invitation has been completed. |
| Sent | Setup email was sent. |
| Expired | The invitation can no longer be used. |
| Failed | One provisioning step did not complete. |
| Active | Credential exists, password is established, and access is enabled. |
| Disabled | Access is blocked and sessions are invalidated. |
Day-to-day workflow
Section titled “Day-to-day workflow”- Open Users.
- Search or select the person.
- Review Email, Role, Active, Provision source, and Access.
- Choose only an action offered for the current state.
- Confirm the resulting state and timestamp.
Do not send a password reset to a person who has never established a password; send or resend the invitation instead.
App Users versus collaborators
Section titled “App Users versus collaborators”| App Users | Collaborators | |
|---|---|---|
| Where they enter | Published app | Builder and My Apps |
| Purpose | Use app data and workflows | Edit, configure, and publish |
| Source | Users database plus app identity | NotionApps team access |
| Password action | App invitation or reset | Maker account reset |
Security behavior
Section titled “Security behavior”- Each app has an isolated password identity. The same email can use separate passwords in separate apps.
- Disable and synced access changes invalidate existing sessions.
- Responses do not expose whether an arbitrary email already has an identity.
- Repeated provisioning retries do not create duplicate identities.
Troubleshooting
Section titled “Troubleshooting”| Symptom | Check |
|---|---|
| Person appears twice | Remove the duplicate Users row; do not provision both. |
| Role is wrong | Fix Role mapping or the row, then sync. |
| Active user sees no screens | Check visibility rules and default role fields. |
| Disabled user still has an old tab | Ask them to reload; the server rejects invalidated sessions. |