Managing roles

Roles help you control what permissions a user has. This allows you to prevent unauthorized access to things such as table views, API Endpoints, and pages in the interface.

To access the roles of your application, visit the Roles tab in Data & API → Authentication:

Understanding roles

Roles are labels you assign to users to control what they can access in your app. They work as a permission system that lets you build different experiences for different types of users.

How roles work

When you create a role, you can then:

1. Assign it to users in the Users tab
2. Restrict access to table views based on roles
3. Restrict access to API Endpoints based on roles
4. Show or hide interface elements based on the user's roles
5. Protect entire pages so only users with specific roles can access them

Roles are enforced automatically by WeWeb when you configure access restrictions. If a user doesn't have the required role, they'll be blocked from accessing that resource.

Creating roles

1. Go to Data & API → Authentication
2. Click the Roles tab
3. Click + Add to create a new role
4. Enter a clear, descriptive role name (for example, user, manager, admin)
5. Save

Keep role names simple, lowercase, and consistent throughout your app. Avoid spaces or special characters.

ROLE NAMING BEST PRACTICES

• Use lowercase for consistency (e.g., admin not Admin)
• Be descriptive but concise (e.g., content_editor not user_who_can_edit_content)
• Match your app's domain (e.g., teacher, student for an education app)
• Avoid changing role names after launch (as it will likely mean you need to update many parts of logic that use old names)

Assigning roles to users

Once you've created roles, you can assign them to users:

1. Go to the Users tab in Data & API → Authentication
2. Select a user from the table
3. In the user details panel, add or remove roles as needed
4. Changes take effect immediately

Users can have multiple roles at the same time. For example, a user could have both user and premium roles.

TESTING WITH ROLES

Create multiple test users with different role combinations to verify your access controls work correctly. For example:

• Test user with no roles (basic authenticated user)
• Test user with admin role
• Test user with premium role

Where roles are enforced

Roles are automatically enforced in multiple places throughout your WeWeb app:

Table views

When you create a view on a table, you can restrict access based on roles:

1. Go to Database & APIs → Tables, then select the table that contains your view.
2. Open the view (it shows as a tab at the top of the table).
3. In the view header, click the access button (it usually shows Public or Authenticated).
4. Choose one of:
   • Public — Anyone can retrieve data from this view (no sign in required).
   • Authenticated — Only signed-in users can retrieve data.
5. If you chose Authenticated, you can also restrict by role:
   • Choose Match any or Match all.
   • Select one or more roles (for example admin).

For example, you might create an "Admin users view" that only users with the admin role can access, while having a separate "Public users view" that anyone can read.

API Endpoints

When you create an API Endpoint, you can restrict who can call it:

1. Open your API Endpoint in Data & API → Backend Workflows → API Endpoints
2. Open the Security panel
3. Choose one of:
   • Public — Anyone can call this API Endpoint (use only for non-sensitive operations)
   • Authenticated — Only signed-in users can call it
   • Specific role — Only users with a particular role can call it

Learn more about securing your API Endpoints: Securing API Endpoints →

Pages

You can protect entire pages so only users with specific roles can access them:

1. Go to Interface and select a page
2. Open the page settings
3. Enable the Private page toggle
4. Configure which roles are required to access the page

When a user without the required roles tries to access a protected page, they'll be redirected to your configured "unauthorized access" page.

Interface elements

You can also show or hide elements in your interface based on the current user's roles using conditional visibility or workflow conditions with the auth data available in the binding window.

Checking roles in workflows

In your workflows and bindings, you can access the current user's roles via the auth data:

• auth.user.roles — Array of role IDs assigned to the current user
• You can use this in conditions to show/hide elements or branch your workflow logic

For example, you might show an "Admin Panel" button only if auth.user.roles contains the admin role ID.

INTERFACE CHECKS ARE NOT SECURE

Using role data in the interface (to show/hide elements or control navigation) improves user experience but does not provide security. Anyone with technical knowledge can bypass interface restrictions by manipulating the browser or directly calling your API Endpoints.

Always enforce security in your backend:

• Restrict table views with the Access setting
• Secure API Endpoints with the Security panel (public/authenticated/role-based restrictions)
• Use Middleware workflows for custom permission logic

Think of interface role checks as a convenience for users, not a security measure. Real security happens on the backend where users cannot bypass it.

CONTINUE LEARNING

Connect sign-in providers so users can authenticate.

Integrating providers →