Users

Users manages the Project Users who can sign in to the application and access protected functionality.

Each Project User has credentials, contact information, a status, and group membership. A user can also have a Web Hook Key for supported authenticated requests.

Project Users are different from Creators. Creators build and manage Projects through the Project Editor; Project Users use the application produced by a Project.

Opening Users

To manage Project Users:

1. Open the Project in the Project Editor.
2. Select Settings.
3. Select Users.

The Users window lists existing usernames and their group membership. Use Search to find users by the supported user search behavior.

User Information

Field	Purpose
Username	Unique name used to sign in. It cannot be changed after the user is created.
Password	Password used for application authentication.
Status	Determines whether the account is allowed to authenticate.
Email	Email address associated with the user and supported account-recovery actions.
First Name	Optional given name.
Last Name	Optional family name.
Phone	Optional phone number.
Web Hook Key	Optional key used for supported authenticated Web Hook or API requests.
Group Membership	Groups and role levels assigned to the user.

Choose usernames that can remain stable. If a username must change, create a replacement user, transfer the intended membership, verify the new account, and then remove or deactivate the original.

Adding a User

To add a Project User:

1. Open Settings → Users.
2. Select Add.
3. Enter a unique Username.
4. Enter a password and required email address.
5. Complete the optional name and phone fields as appropriate.
6. Choose the account status.
7. Add the user's group membership and role level.
8. Select Save.

Adding a user does not require republishing. The account can be used for subsequent sign-ins when the published application and its protected resources are otherwise available.

Provide credentials through an appropriate secure channel. Do not send passwords or Web Hook Keys through public messages, issue descriptions, or documentation.

Editing a User

Select a user and choose Edit to change supported account information.

You can update:

• Password.
• Status.
• Email address.
• First and last name.
• Phone number.
• Web Hook Key.
• Group membership and role levels.

The Username remains fixed.

User changes do not require republishing. Updated credentials and access are used for subsequent authentication.

Existing Sessions

A user who is already signed in may continue with the access associated with their current session. After changing membership or other access-related information, have the affected user sign out and sign in again.

Do not assume that changing a password, deactivating an account, or deleting a user immediately ends every existing session. For urgent access removal, consider the active-user impact and verify that protected resources remain appropriately secured.

User Status

Only an active account can authenticate normally. Use a non-active status when access should be prevented without immediately deleting the user record.

Status changes do not require republishing and are applied to subsequent authentication attempts. Existing-session considerations still apply.

Use deactivation when the account may need to be reviewed or restored. Use deletion when the account should no longer be retained in the Project.

Group Membership

Group membership determines which group identities and role levels the user presents when accessing protected Project resources.

All authenticated Project Users belong to All Users. A user can additionally belong to one or more custom groups, each at an assigned role level. A user assigned to Admin receives the broad administrator access associated with that built-in group.

To change membership:

1. Edit the user.
2. Select a group.
3. Select the appropriate role level.
4. Choose Add.
5. Remove memberships that are no longer required.
6. Save the user.
7. Have an already signed-in user sign out and sign in again.

Membership does not configure the resource itself. Pages, tables, Connections, Cloud Flow modules, AI Agents, and other protected resources must also be configured to allow the intended group and role level.

For group identities and role behavior, see User Groups.

Passwords

Passwords protect interactive application sign-in. Use a unique password appropriate to the sensitivity of the application.

When setting or resetting a password:

• Share it through a secure channel.
• Avoid reusing credentials from another service.
• Test the new credentials through the intended published domain.
• Ask the user to replace temporary credentials when the surrounding application workflow supports that practice.

Changing a password affects subsequent sign-ins. It should not be treated as a guaranteed way to terminate every current session.

Web Hook Keys

A Web Hook Key can identify a Project User when calling supported Project endpoints that accept key-based authorization. Requests made with the key are subject to the permissions assigned to that user.

For a Cloud Flow Web Hook, send the key in the HTTP Authorization header using the Bearer scheme. For the complete request format, access behavior, and example, see Web Hooks — Calling as a Project User.

To create or replace a key:

1. Edit an existing user.
2. Select the generate-key action beside Web Hook Key.
3. Copy the generated key.
4. Save the user.
5. Store the key in the calling system's secret or credential manager.
6. Test the intended request and its denied cases.

Treat a Web Hook Key like a password:

• Do not embed it in browser-side JavaScript.
• Do not commit it to source control.
• Do not include it in public documentation or screenshots.
• Send it only over HTTPS.
• Replace it when exposure is suspected.
• Grant the associated user only the membership required by the endpoint.

Creating a new key does not require republishing. However, an old key may not stop working immediately. Plan sensitive key replacement as a credential-rotation operation and verify that the old key is no longer accepted before considering rotation complete.

Web Hook access also depends on the Web Hook's own Access (Security) configuration and any authorization enforced by its Cloud Flow. A valid user key does not automatically authorize every Project operation.

Deleting a User

To delete a user:

1. Locate the user in Settings → Users.
2. Select the user action menu.
3. Choose Delete.
4. Confirm the deletion.

Before deleting the account:

• Identify automated callers using its Web Hook Key.
• Decide whether records that refer to the username need to be retained or reassigned.
• Consider whether the user has an active application session.
• Verify that another administrator remains available when applicable.

Deleting a Project User does not delete application records created by that user unless a separate application workflow explicitly does so.

Deletion does not require republishing. It affects subsequent authentication, subject to existing-session considerations.

Testing User Access

Test access from the same published context that users will use:

1. Sign out of any existing Project User session.
2. Sign in as the test user.
3. Open permitted Pages directly and through normal navigation.
4. Attempt to open a Page the user should not access.
5. Exercise permitted and denied Database operations.
6. Test protected Connections, Cloud Flow entry points, and AI Agent interfaces as applicable.
7. Repeat with representative group and role combinations.

Hiding a link or button is not an authorization test. Attempt the protected operation and verify that access is denied at the resource boundary.

Good Practices

• Give each person an individual account instead of sharing credentials.
• Assign the smallest set of groups and role levels required.
• Use non-active status when access must be paused but the account should be retained.
• Review users periodically and remove access that is no longer needed.
• Store Web Hook Keys in a secret manager and rotate them when appropriate.
• Retest access after changing membership or resource permissions.
• Keep at least one verified administrator account available for protected applications.

Common Mistakes

Avoid these patterns:

• Confusing Project Users with Creators.
• Expecting a Username to be editable after creation.
• Assuming group membership protects a resource that has not been configured with Access (Security).
• Assuming a changed or deleted user is immediately removed from every active session.
• Sharing a single administrator account among several people.
• Placing a Web Hook Key in frontend code or a public URL.
• Granting Admin membership only to avoid configuring appropriate resource access.
• Testing access while still signed in through an older session.

Related Topics

• Settings
• User Groups
• Page Settings — Access (Security)
• Table Access
• Access and Security
• Connections
• Creators