How to Set Up Role-Based Access in Your Portal
Why Role-Based Access Matters
Not every portal user should see the same pages. In a client portal, the account owner might need billing and user management pages, while team members only need the project dashboard. In a course portal, instructors need to create and grade assignments, while students only need to view lessons and submit work. Without role-based access, either everyone sees everything (which creates confusion and security risks) or you build separate portals for each user type (which doubles your work).
Role-based access solves this by tagging each user with a role and then checking that role before rendering pages and actions. One portal, multiple experiences.
How Roles Work on the Platform
The platform supports roles through the sub-user system in the Account Admin app. The primary account owner is the top-level admin. Sub-users are additional logins attached to the same account, each with their own credentials and permission set. You define what each sub-user can access by configuring their allowed apps and pages.
Roles are not a fixed list. You define whatever roles make sense for your business. A simple portal might just have "admin" and "member." A complex one might have "owner," "manager," "editor," "viewer," and "guest." The role is stored as a field on the sub-user record, and your portal pages check it before rendering.
Setting Up Roles
List the different user types your portal needs and what each type should be able to do. For each role, decide which pages they can see, whether they can create or delete records, and whether they can manage other users. Keep roles simple and avoid creating more than you actually need.
In the Account Admin app, set up sub-user profiles for each role. Each sub-user record specifies which apps and pages that user can access. When a sub-user logs in, the portal checks their permissions and only shows the navigation items and pages they are allowed to see.
Individual database pages can be restricted using the superOnly flag in the slug configuration. When superOnly is set, only the account owner can access that page. For more granular control, you can add custom role-checking logic that reads the logged-in user's role and conditionally renders page content.
Beyond hiding pages, you can restrict specific actions. The canCreateNewData, canUpdateData, and canDeleteData flags in each slug control whether those operations are available. You can set different permissions per role by using separate slugs for the same data, one slug for admin users with full CRUD and another for regular users with read-only access.
Common Role Patterns
Two-Role Portal (Admin and Member)
The simplest pattern. The account owner sees all pages including user management, billing, and configuration. Members see only the data pages relevant to them. This works for most client portals and membership sites.
Three-Role Portal (Admin, Manager, Member)
Adds a middle tier that can manage day-to-day operations without access to billing or system settings. Managers can edit records and view reports but cannot add or remove users. Common for agency portals where project managers need more access than clients.
Read-Only Viewer Role
A restricted role that can view data pages but cannot create, edit, or delete any records. Useful for stakeholders who need visibility into the portal data without the ability to change anything. Implement by setting canCreateNewData, canUpdateData, and canDeleteData all to false in the viewer's slug configuration.
Set up role-based access to control what each user sees in your portal. Admin, manager, member, and custom roles.
Get Started Free