User management

Requirements

User management is available on Starter and higher. Free workspaces cannot enable end-user accounts. The toggle lives in Project Settings alongside email template configuration.

App users vs platform users

Platform users sign into prowpt.ai to edit. App users authenticate against your published slug only and never receive builder permissions.

• JWTs are scoped per project slug.
• Profile record types can mirror app user fields for CRM-style data.
• Backoffice user lists help moderators inspect accounts.

Email templates

Customize verification, password reset, and notification templates per project. Workflows that send email can reuse the same templating system with merge fields.

Google SSO (Single Sign-On)

Enable Google Sign-In so app users can authenticate with their Google account instead of (or in addition to) email/password. The OAuth flow is handled entirely server-side—no client secrets are exposed to your generated app.

• Toggle 'Enable Google Sign-In' under User Management → SSO in project settings.
• Platform-wide Google OAuth credentials are used by default. Project-level overrides are possible.
• New users signing in with Google are created automatically with a verified email.
• Existing users with a matching email are linked to their Google account on first SSO login.
• The assistant automatically adds a 'Sign in with Google' button when SSO is enabled.

Roles and permissions (RBAC)

Beyond per-record-type access policies, you can define project-wide roles for your app users — moderators, support staff, VIPs, etc. Each role has a permission matrix that grants specific CRUD actions on specific record types, regardless of who owns the row. Manage roles from the new Permissions tab in the backoffice.

• Each role has a name (1–64 chars, unique per project), an optional description, and a per-record-type, per-action grant matrix (read / create / update / delete).
• Exactly one role per project may be flagged as the default — new app-user signups are auto-assigned to it. Promoting a role to default automatically demotes the previous default in the same operation.
• Role grants are unioned with each record type's access_policy: a permission grant lets the user act on ANY row of that type, including rows owned by other users (the owner check is bypassed when the role grant applies).
• Roles default to no grants — you can create a role as a label first and configure the matrix later, or seed grants at creation time.
• Deleting a role un-assigns every user who carried it (they fall back to the universal-floor permissions only).

Assigning roles to app users

On the App Users tab in the backoffice each user row shows a Role dropdown listing the project's roles. Pick one to assign, or pick None to clear the assignment and fall back to the universal floor. The dropdown is empty until you create at least one role under the Permissions tab.

Approval queue for sensitive RBAC changes

Changes to a record type's access_policy or to any app-user role (create / update / delete / assign) are routed through an approval queue when the caller cannot be fully trusted to make the change unattended. As the project owner you review and approve or reject each pending change from the backoffice.

• Pending changes appear as a yellow banner at the top of the backoffice with a count and a Review button. The drawer shows each change's kind, the originating connector, the human-readable summary, the raw payload, and Approve / Reject buttons with an optional reason.
• Pending changes expire after 1 hour. The approval action only runs if the queue still has the change in the pending state — you can't approve an expired or already-decided change.
• Every queue action (queued, approved, rejected, applied, failed) emits a structured rbac_change_* security event so the audit trail is complete.
• The approver must be a signed-in web session — API keys and OAuth tokens explicitly cannot approve their own queued changes.