Private apps
A private app requires every protected visitor to authenticate before using the published app. Use it for staff tools, client portals, member areas, commercial data, and any app where records should not be open to anonymous visitors.
Selected screens can still be public through per-screen public access. That does not make the whole app public.
Before you start
Section titled “Before you start”- Link a Users database.
- Map a writable Name property and the email property used for login.
- Decide whether access is invitation-only or self-service.
- Decide which login method users should see first.
Make an app private
Section titled “Make an app private”- Open the app in Builder.
- Open Users.
- Change app access from Public to Private.
- Choose the primary login method: Email OTP or Email & password.
- Optionally add Google, Auth0, Okta, or another supported method.
- Configure provider credentials under Integrations when required.
- Decide whether Allow users to sign up should be on.
- Publish.
- Open the published URL in a private browser window and complete the login flow.
Invitation-only email and password
Section titled “Invitation-only email and password”Use this setup when a maker must decide exactly who can enter:
- Set the app to Private.
- Select Email & password.
- Keep Allow users to sign up off.
- Open Users and choose Add User.
- Enter the person’s name and email and choose a role if roles are configured.
- Select Add user and send invitation.
- The user opens the email, establishes a password, and returns to the app.
- Confirm the user shows Active before relying on the account.
Only the invited email can complete that app-specific setup. The maker never chooses the password.
Login controls
Section titled “Login controls”| Control | Purpose |
|---|---|
| Public / Private | Turns the app-wide login gate off or on. |
| Primary login method | Chooses the first sign-in flow. |
| Additional login methods | Adds other provider buttons. |
| Allow users to sign up | Lets eligible visitors create themselves. Leave off for controlled access. |
| Default user fields | Sets Role, Active, and other values for signup and Builder Add User. |
| Per-screen public access | Allows selected guest screens without opening the whole app. |
What users see
Section titled “What users see”Email-and-password users see email, password, Forgot password, and Create account only when signup is enabled. Invited users use the invitation email first. Additional providers appear as separate buttons after they are configured and published.
Access removal
Section titled “Access removal”Use Disable in the user’s access controls to block login immediately and invalidate existing sessions. Re-enable restores eligibility but does not reveal or replace the password. Deleting or changing a Users-database row also reconciles access during sync, but using Disable first gives the maker an explicit, visible action.
Troubleshooting
Section titled “Troubleshooting”| Symptom | Check |
|---|---|
| Login page does not appear | Confirm the app is Private and republished. |
| User cannot establish a password | Confirm the invitation is current; resend when expired or failed. |
| Anyone can create an account | Turn Allow users to sign up off and publish. |
| User signs in but sees no screens | Check Role, Active, visibility rules, and default user fields. |
| Provider button is missing | Configure the integration, enable it as an additional method, and publish. |