User Groups

User Groups organize Project Users for application access. They provide reusable identities that can be assigned to users and referenced by Access (Security) settings throughout the Project.

For example, a Project can use custom groups for Customers, Support Staff, Editors, or Regional Managers, then allow those groups to open particular Pages or perform selected operations.

How User Groups Work

Access involves both membership and resource configuration:

• A Project User belongs to one or more groups at assigned role levels.
• A protected resource specifies which groups and minimum role levels may access it.
• Access is granted when the signed-in user's membership satisfies the resource's rule.

User Groups can be used by Pages, Database tables, Connections, Cloud Flow modules, AI Agents, and other resources that provide Access (Security) settings.

Changing a group name does not automatically add users to it or protect any resource. Membership and resource access must be configured separately.

Opening User Groups

To manage group names:

1. Open the Project in the Project Editor.
2. Select Settings.
3. Select User Groups.

The window displays the built-in and custom groups available to the Project.

Built-in and Custom Groups

Group	Behavior
Public (No Password)	Represents access that does not require a Project User to sign in.
All Users	Represents every authenticated Project User.
Custom Groups	Ten groups that can be renamed for the Project's access model.
Admin	Represents Project Users with application administrator access.

The built-in Public, All Users, and Admin group names cannot be changed. Custom groups can be renamed.

Public Access

Use Public (No Password) only when the resource is intentionally available without authentication.

Public access is appropriate for resources such as a public landing page or a narrowly permitted contact submission. It is generally inappropriate for private records, administrative operations, credentials, or sensitive workflows.

If a resource allows Public access, requiring a user to belong to another group does not make that same resource private.

All Users

Every authenticated Project User is part of All Users. Use this group when any signed-in user should be permitted, regardless of custom membership.

All Users is useful for shared account pages and general authenticated functionality. Do not use it for operations intended only for a department, customer category, or administrator.

Custom Groups

The Project provides ten custom groups. Rename them to represent stable application responsibilities or audiences.

Examples include:

• Customers
• Support
• Content Editors
• Finance
• Regional Managers

Renaming a custom group preserves its existing user memberships and access assignments. The new name appears wherever that group is selected in the Project Editor.

Before renaming a group, confirm that the new name still accurately describes every user and resource already assigned to it.

Admin

The Admin group provides broad application administrator access. Assign it only to trusted Project Users who require that level of control.

Application Admin is different from Creator or account-administrator access. It applies to the application and does not grant Project Editor, billing, or account-management privileges.

Role Levels

Groups support five ordered role levels:

Level	Role
1	Staff Level 1
2	Staff Level 2
3	Supervisor
4	Manager
5	Dept Lead

When a resource is configured with a group and role level, that level acts as the minimum required level for the group. A user with a higher role level in the same group also satisfies the rule.

For example, if a Connection operation requires Support: Supervisor, users assigned as Support Supervisor, Manager, or Dept Lead can satisfy the rule. Support users at Staff Level 1 or Staff Level 2 cannot.

Role levels apply within each group. Being a Manager in one group does not make the user a Manager in another group.

Renaming a Custom Group

To rename a group:

1. Open Settings → User Groups.
2. Locate the custom group.
3. Replace its name with the intended label.
4. Select Save.

Renaming a group does not require republishing and does not change its existing membership or access assignments.

After renaming:

• Review user memberships for accuracy.
• Review important Access (Security) settings using that group.
• Tell other Creators about the terminology change.
• Update external team procedures or documentation that use the previous name.

Avoid reusing an existing group for an unrelated purpose merely by renaming it. Existing assignments remain attached to the group and may grant unintended access under its new meaning.

Assigning a User to a Group

Group names are managed under User Groups, but membership is managed on the user:

1. Open Settings → Users.
2. Add or edit a Project User.
3. Select the custom group or Admin group.
4. Select the appropriate role level when available.
5. Choose Add.
6. Repeat for any additional memberships.
7. Save the user.

All Users membership is automatic. Public is an access choice for resources, not a membership that needs to be assigned to a user.

Membership changes do not require republishing. A user who is already signed in may need to sign out and sign in again before the change is reflected.

Protecting a Resource with a Group

To apply a group to a resource:

1. Open the resource's Access (Security) settings.
2. Remove Public access if authentication is required.
3. Select the intended group.
4. Select the minimum role level.
5. Add the access rule.
6. Save the resource.
7. Publish when required for that type of resource.
8. Test with both permitted and denied users.

The exact operations vary by resource. A Database table can have different rules for View, Add, Modify, and Delete. A Connection can expose service-specific operations. A Cloud Flow Web Hook can have its own entry-point access even when the flow calls other trusted resources.

Configure each operation according to what the user needs. Avoid granting a broad operation merely because another operation is required.

Example Access Model

Consider a support application with three custom groups:

Group	Typical Membership	Example Access
Customers	Application customers	View their portal and submit requests.
Support	Support team members	View and update support requests.
Operations	Operational staff	View reports and manage service data.

Within Support:

• Staff Level 1 can view assigned requests.
• Supervisor can access escalation operations.
• Manager can access team reporting.

This model still requires appropriate access rules on the Pages, tables, Connections, and workflows involved. The group names alone do not enforce those boundaries.

Access Across Project Areas

Area	What Group Access Controls
Pages and Forms	Who can open the published Page or Form.
Database	Who can perform configured View, Add, Modify, and Delete operations.
Connections	Who can invoke the operations exposed by the Connection.
Cloud Flow	Who can invoke applicable client-accessible modules or Web Hooks.
AI Agents	Who can access the Agent through applicable client interfaces.

These controls complement one another. Allowing a group to open a Page does not automatically authorize the Page's Database operations or Connections.

Trusted backend workflows can also require explicit authorization logic depending on how they are invoked. Review each boundary rather than assuming access propagates automatically.

Publishing Behavior

Renaming a custom group does not require republishing because the group's existing identity and assignments remain the same.

Other access changes can require publishing:

• User membership changes apply to subsequent authentication without publishing.
• Page access changes require the changed Page to be published.
• Database structure and access changes follow the Database publishing lifecycle.
• Connection and Cloud Flow access changes must be published when they need to affect the published application.

After publishing an access change, test with a new sign-in for each representative user type.

Good Practices

• Name groups for stable responsibilities or audiences, not temporary projects or individual people.
• Grant the minimum required role level.
• Keep Admin membership limited and review it regularly.
• Remove Public access whenever authentication is intended.
• Test both allowed and denied operations.
• Document the intended purpose of each custom group for the Project team.
• Review group usage before repurposing or renaming a group.
• Protect underlying data and operations in addition to Pages.

Common Mistakes

Avoid these patterns:

• Confusing Project User Groups with Creator permissions.
• Treating a group name as an access rule by itself.
• Assuming All Users means every internet visitor.
• Leaving Public access enabled on a resource intended to require sign-in.
• Assuming a role level in one group applies to another group.
• Renaming an existing group for a new purpose without reviewing its current assignments.
• Protecting a Page while leaving its underlying data or operation too broadly accessible.
• Testing membership changes without starting a new user session.

Related Topics

• Settings
• Users
• Page Settings — Access (Security)
• Table Access
• Access and Security
• Connections
• Creating and Configuring AI Agents