Users overview

The Users section controls who can sign in to a private app, how they establish credentials, what role they receive, and whether their access remains active. App users are not maker collaborators: app users enter the published app; collaborators edit the app in Builder.

Choose the right user workflow

Goal	Use
Only named people may enter with email and password	Private apps + Email & password + Add User. Keep public signup off.
Anyone who meets your signup rules may create an account	Sign up. Configure domains, legal links, and default fields.
Add, invite, disable, reset, or re-enable one person	Add/Remove users and App Users.
Map Role, Active, and profile properties	Identity admin.
Decide primary and additional login methods	Auth and access.
Limit records by the logged-in user	Data Restriction.

Recommended invitation-only setup

Create and link a Users database with writable Name and Email properties.
Open Users and change the app to Private.
Select Email & password as the login method.
Leave Allow users to sign up off.
Configure Role and Active mappings when the app uses them for navigation or access.
Select Add User, enter the person’s name and email, choose a role when offered, and send the invitation.
Watch the access state until it becomes Active.
Test the published URL in a private browser window.

The maker never creates or sees the user’s password. The invited person receives a secure, expiring link and establishes the password on a branded page for the app.

User lifecycle

State	Meaning	Maker action
Not invited	User row exists but password setup has not been sent	Send invitation.
Sent	Invitation was sent and is waiting for the user	Wait or resend when needed.
Expired	The setup link can no longer be used	Resend invitation.
Failed	Provisioning or delivery did not complete	Read the issue and retry.
Active	Password was established and access is enabled	Reset password or disable.
Disabled	Login is blocked and existing sessions are invalidated	Re-enable when access should return.

Public signup and maker-controlled users solve different problems. Turning signup on allows eligible visitors to create themselves. Adding a user from Builder authorizes one named email while signup stays off. For an internal tool, staff portal, or private client portal, keep signup off unless self-enrollment is intentional.