Roles are the primary mechanism for controlling access in Tadabase applications. A role defines what a user can see and do - which pages they can access, which components they can view, and which actions they can perform. In this article, you'll master role-based access control (RBAC) and learn to implement sophisticated permission systems.

A role is a set of permissions assigned to a group of users. Instead of setting permissions for each individual user, you create roles that represent different types of users and assign permissions to those roles.

Role Examples

Typical roles in different applications:

CRM Application

• Admin - Full system access
• Sales Manager - View all leads, manage sales team
• Sales Rep - View and edit own leads
• Support - View customer data, limited editing

Project Management App

• Admin - Full access
• Project Manager - Manage assigned projects
• Team Member - View projects, edit own tasks
• Client - View own projects only

HR System

• HR Admin - Full employee data access
• Manager - View team data, approve requests
• Employee - View/edit own information

Benefits of Roles

• Simplified Management - Set permissions once per role, not per user
• Consistency - All users with the same role have identical permissions
• Scalability - Easy to add new users with appropriate access
• Maintainability - Change role permissions to affect all users in that role
• Clarity - Clear definition of who can do what

Every Tadabase app comes with a default Admin role. You'll create additional roles based on your needs.

How to Create a Role

1. Go to Settings → Roles
2. Click "Add Role"
3. Enter a Role Name (e.g., "Manager", "Customer", "Employee")
4. Optionally add a Description (helps document the role's purpose)
5. Click "Create"

Role Naming Best Practices

• Use clear, descriptive names (avoid abbreviations)
• Use titles or job functions (Manager, Sales Rep, Customer)
• Be consistent with naming conventions
• Consider hierarchy (Admin, Manager, Employee)
• Avoid technical jargon (unless appropriate for your users)

Default Role

You can designate a role as the Default Role:

• New users are automatically assigned this role when they sign up
• Useful for self-registration scenarios
• Typically set to the lowest privilege role (e.g., "Customer" or "Guest")
• Can be changed later by administrators

To set default role:

1. Go to Settings → Roles
2. Click on a role
3. Check "Default Role for New Signups"
4. Save

The most fundamental permission is controlling which pages each role can access.

How Page Permissions Work

For each page in your app, you specify which roles can access it:

• If a role has permission, users in that role can view the page
• If a role doesn't have permission, the page doesn't appear in navigation and cannot be accessed directly
• You can assign multiple roles to each page

Setting Page Permissions

Method 1: From Page Settings

1. Go to Page Builder
2. Select a page
3. Click Page Settings (gear icon)
4. Go to Permissions tab
5. Check the boxes for roles that should access this page
6. Save

Method 2: From Roles Settings

1. Go to Settings → Roles
2. Select a role
3. Click Page Permissions
4. Check the boxes for pages this role should access
5. Save

Public Pages

Public pages can be accessed without logging in:

1. In Page Settings → Permissions
2. Check "Public Page"
3. Page is now accessible to anyone
4. Useful for login, signup, contact forms, marketing pages

Page Permission Examples

Example 1: Basic App Structure

Page Name	Admin	Manager	Employee	Public
Login	-	-	-	✓
Signup	-	-	-	✓
Dashboard	✓	✓	✓	-
All Projects	✓	✓	-	-
My Projects	✓	✓	✓	-
User Management	✓	-	-	-
Reports	✓	✓	-	-
Settings	✓	-	-	-

Example 2: Customer Portal

Page Name	Admin	Staff	Customer	Public
Login	-	-	-	✓
All Orders	✓	✓	-	-
My Orders	✓	-	✓	-
All Customers	✓	✓	-	-
My Account	✓	-	✓	-
Submit Order	✓	-	✓	-
Admin Dashboard	✓	-	-	-

You can control which components are visible to which roles on any given page.

Why Use Component Permissions?

Multiple roles might access the same page but see different things:

• Admin sees all data; Manager sees team data; Employee sees own data
• Different charts/reports for different roles
• Show action buttons only to appropriate roles
• Conditional functionality based on role

Setting Component Permissions

1. Go to Page Builder and select a page
2. Click on a component
3. Go to Settings (or Display Rules depending on component)
4. Find "Roles That Can View This Component"
5. Select applicable roles
6. Save

If no roles are selected, the component is visible to all roles that can access the page.

Component Permission Examples

Example 1: Dashboard with Role-Specific Widgets

Create one "Dashboard" page, but show different components to different roles:

• Sales Chart - Visible to: Admin, Sales Manager
• My Sales - Visible to: Admin, Sales Manager, Sales Rep
• Revenue Report - Visible to: Admin only
• My Tasks - Visible to: All roles
• User Management Button - Visible to: Admin only

Example 2: Project Details Page

Different action buttons based on role:

• Edit Project Button - Visible to: Admin, Project Manager
• Delete Project Button - Visible to: Admin only
• Add Comment Button - Visible to: All roles
• Assign Tasks Button - Visible to: Admin, Project Manager
• Financial Tab - Visible to: Admin, Finance

Example 3: Data Table with Different Views

Show different columns based on role:

• Create multiple table components on the same page
• Full Table (all columns) - Visible to: Admin
• Manager Table (most columns) - Visible to: Manager
• Employee Table (limited columns) - Visible to: Employee

Control which fields are visible and editable for each role within forms and details components.

How Field Permissions Work

For each field in a form or details component, you can set:

• Visible to which roles - Which roles can see the field
• Editable by which roles - Which roles can modify the field
• Required for which roles - Which roles must fill in the field

Setting Field Permissions

In Form Components

1. Add or edit a Form Component
2. Click on a field in the form
3. In field settings, find "Field Permissions"
4. Configure visibility and editability by role
5. Save

In Details Components

1. Add or edit a Details Component
2. Click on a field in the details layout
3. Configure which roles can see the field
4. Save

Field Permission Options

Setting	Description	Use Case
Visible	Field is displayed	Show salary to HR and Admin only
Hidden	Field is not displayed	Hide sensitive fields from certain roles
Editable	Field can be modified	Allow managers to edit status
Read-Only	Field is visible but not editable	Show price to customers but they can't change it
Required	Field must be filled in	Managers must provide approval notes

Field Permission Examples

Example 1: Employee Record Form

Field	Admin	Manager	Employee
Name	Edit	View	Edit
Email	Edit	View	Edit
Phone	Edit	View	Edit
Department	Edit	Edit	View
Salary	Edit	Hidden	Hidden
Performance Rating	Edit	Edit	View
Social Security #	Edit	Hidden	Hidden

Example 2: Order Form

Field	Admin	Sales	Customer
Product	Edit	Edit	Edit
Quantity	Edit	Edit	Edit
Price	Edit	Edit	View
Discount	Edit	Edit	Hidden
Cost	View	Hidden	Hidden
Status	Edit	Edit	View
Internal Notes	Edit	Edit	Hidden

Example 3: Approval Workflow

Field	Admin	Manager	Employee
Request Type	View	View	Edit
Description	View	View	Edit
Amount	View	View	Edit
Approval Status	Edit	Edit	View
Approval Notes	Edit	Edit (Required)	View
Approved By	View	View	View

Action links (buttons that trigger actions) can also be restricted by role.

Common Action Link Use Cases

• Edit - Only managers and admins can edit
• Delete - Only admins can delete
• Approve - Only managers can approve
• Submit - All roles can submit
• Export - Only admin and managers can export

Setting Action Link Permissions

1. In a component (table, details, etc.), click on an action link
2. Find "Roles That Can Use This Action"
3. Select applicable roles
4. Save

Example: Table Action Links

A Projects table with role-specific actions:

• View Details - All roles (Admin, Manager, Employee)
• Edit - Admin, Manager only
• Delete - Admin only
• Assign Team Member - Admin, Manager only
• Mark Complete - Admin, Manager only
• Add Comment - All roles

Employees will only see "View Details" and "Add Comment" buttons. Managers will see more actions. Admins will see all actions.

Beyond what users can see (pages/components), you can control what data they can access.

Filtering Data by Role

Use filters in components to show different data to different roles.

Example: Sales Dashboard

• Admin - Sees all sales (no filter)
• Manager - Sees sales for their region (filter: Region = Manager's Region)
• Sales Rep - Sees only their own sales (filter: Salesperson = Logged In User)

Implementation Approaches

Approach 1: Multiple Components

1. Create separate table components for each role
2. Set role visibility on each component
3. Apply appropriate filters

Approach 2: Dynamic Filters with Conditional Logic

1. Use a single component
2. Create page criteria that vary by role
3. Apply conditional filters based on logged-in user

Approach 3: Owner-Based Filtering (covered in detail in Article 6)

1. Use connection fields to link records to users
2. Filter: "Owner" = "Logged In User"
3. Automatically shows users only their records

While Tadabase doesn't have built-in role hierarchy, you can design your roles hierarchically.

Conceptual Hierarchy

Think of roles as layers of access:

1. Admin - Full access to everything
2. Manager - Access to most things, limited admin functions
3. Employee - Access to work-related pages, own data
4. Customer - Access to customer portal, own orders
5. Guest - Very limited access, public pages only

Implementing Hierarchical Permissions

When setting permissions:

• Higher-level roles get all permissions of lower-level roles, plus more
• Admin role should always have access to everything
• Each level down has progressively fewer permissions

Example Permission Matrix

Feature	Admin	Manager	Employee	Customer
View Dashboard	✓	✓	✓	✓
View All Records	✓	✓	-	-
View Own Records	✓	✓	✓	✓
Edit All Records	✓	✓	-	-
Edit Own Records	✓	✓	✓	✓
Delete Records	✓	✓	-	-
Manage Users	✓	-	-	-
View Reports	✓	✓	-	-
Export Data	✓	✓	-	-
App Settings	✓	-	-	-

Always test permissions thoroughly before going live.

Creating Test Users

1. Create a test user for each role
2. Use obvious email addresses (admin-test@example.com, manager-test@example.com)
3. Document test user credentials
4. Use these accounts for ongoing testing

Testing Process

1. Log in as each test user
2. Verify page access - Can they access pages they should? Are pages they shouldn't see hidden?
3. Check component visibility - Do they see appropriate components?
4. Test field permissions - Can they edit fields they should? Are sensitive fields hidden?
5. Try actions - Can they perform allowed actions? Are restricted actions unavailable?
6. Check data filtering - Do they see only the data they should?
7. Test edge cases - What happens if they try to access pages directly via URL?

Common Testing Scenarios

Scenario 1: Restricted Page Access

1. Log in as Employee
2. Try to access Admin-only page by typing URL directly
3. Should be redirected or see "Access Denied"

Scenario 2: Component Visibility

1. Log in as Manager
2. View dashboard
3. Verify you see manager components but not admin-only components

Scenario 3: Field Editing

1. Log in as Employee
2. Try to edit a record
3. Verify sensitive fields are read-only or hidden
4. Verify allowed fields can be edited

Scenario 4: Data Filtering

1. Log in as Sales Rep
2. View sales list
3. Verify you only see your own sales, not all sales

Follow these guidelines for effective role management:

1. Principle of Least Privilege

• Give users only the permissions they need
• Start with minimal access and add as needed
• Don't make everyone an admin
• Review and adjust permissions regularly

2. Keep Roles Simple

• Don't create too many roles (harder to manage)
• Use 3-7 roles for most applications
• Make role purposes clear
• Combine similar roles when possible

3. Document Roles

• Add descriptions to each role
• Create a permission matrix (spreadsheet or table)
• Document why each permission was granted
• Keep documentation updated

4. Plan Before Building

• Map out roles before creating pages
• Identify user types and their needs
• Create permission matrix upfront
• Design pages with roles in mind

5. Consistent Naming

• Use consistent role names across apps
• Use business-friendly terms (not technical jargon)
• Make role names self-explanatory

6. Avoid Over-Complication

• Don't create role combinations for every scenario
• Use page rules for complex conditional access (covered in next article)
• Balance security with usability

7. Regular Audits

• Review role assignments quarterly
• Remove permissions that are no longer needed
• Verify new features have appropriate permissions
• Update documentation

8. Test Thoroughly

• Always test as each role
• Test before and after making changes
• Verify security before going live
• Have others test (they'll find things you miss)

Here are typical role configurations for common application types:

Scenario 1: CRM Application

Roles

• Admin - Full system access
• Sales Manager - View all leads, edit team data, reports
• Sales Rep - View/edit own leads and opportunities
• Support - View customer data, add support tickets

Key Permissions

Feature	Admin	Sales Mgr	Sales Rep	Support
View All Leads	✓	✓	-	-
View Own Leads	✓	✓	✓	-
Edit All Leads	✓	✓	-	-
Create Leads	✓	✓	✓	-
Delete Leads	✓	-	-	-
View Reports	✓	✓	-	-
View Customers	✓	✓	✓	✓
Manage Users	✓	-	-	-

Scenario 2: Project Management

Roles

• Admin - Full system access
• Project Manager - Manage assigned projects
• Team Member - Work on assigned tasks
• Client - View own projects, read-only

Key Permissions

Feature	Admin	PM	Team	Client
Create Projects	✓	✓	-	-
Edit All Projects	✓	-	-	-
Edit Own Projects	✓	✓	-	-
View All Projects	✓	-	-	-
View Assigned Projects	✓	✓	✓	✓
Create Tasks	✓	✓	✓	-
Edit Own Tasks	✓	✓	✓	-
View Time Reports	✓	✓	-	-
View Budget	✓	✓	-	-

Scenario 3: Customer Portal

Roles

• Admin - Internal administrator
• Staff - Internal employees
• Customer - External customers

Key Permissions

Feature	Admin	Staff	Customer
View All Orders	✓	✓	-
View Own Orders	✓	-	✓
Create Orders	✓	✓	✓
Edit Orders	✓	✓	-
View All Customers	✓	✓	-
Edit Own Profile	✓	-	✓
View Invoices	✓	✓	✓ (own)
Submit Support Tickets	✓	-	✓
View Reports	✓	✓	-

In this article, you learned:

• What roles are - Sets of permissions assigned to user groups
• Creating roles - How to define roles in Tadabase
• Page-level permissions - Controlling which pages each role can access
• Component-level permissions - Showing different components to different roles
• Field-level permissions - Controlling field visibility and editability
• Action link permissions - Restricting actions based on role
• Data permissions - Filtering data differently for each role
• Testing roles - Verifying permissions work correctly
• Best practices - Guidelines for effective role management
• Common scenarios - Real-world role configurations

Roles provide the foundation for access control in Tadabase. Combined with other security features, they enable you to build sophisticated, secure multi-user applications.

In the next article, you'll learn about page rules and advanced access control - how to implement conditional, dynamic permissions that go beyond role-based access.

Hands-On Exercise (To Be Added)

Exercise placeholders will include practical activities such as:

• Creating multiple roles (Admin, Manager, Employee)
• Configuring page permissions for each role
• Setting up component visibility by role
• Configuring field permissions in forms
• Testing permissions with different user accounts
• Building a permission matrix for your app

Knowledge Check (To Be Added)

Quiz questions will test understanding of:

• What roles are and why they're important
• How to set page-level permissions
• Difference between component and field permissions
• When to use different permission types
• Best practices for role management
• How to test role permissions