While role-based permissions provide a solid foundation for security, sometimes you need more dynamic, conditional access control. Page rules allow you to implement sophisticated, context-aware permissions based on user attributes, data values, and complex conditions. In this article, you'll learn to implement advanced access control that goes beyond simple role assignments.

Page rules are conditional logic statements that control page access and behavior dynamically. Unlike static role permissions, page rules evaluate conditions in real-time when a user attempts to access a page.

Page Rules vs. Role Permissions

Feature	Role Permissions	Page Rules
Basis	User's role	Dynamic conditions
When Evaluated	At login	Every page access
Complexity	Simple (role = access)	Complex (multiple conditions)
Use Case	Basic access control	Conditional access
Example	"Managers can access"	"Managers from Sales dept can access"

When to Use Page Rules

Use page rules when:

• Access depends on user attributes (department, status, etc.)
• Access depends on data values (subscription level, account status)
• Different users within the same role need different access
• Access changes based on time or other dynamic factors
• You need to redirect users based on conditions
• Access depends on relationships (manager of team, owner of record)

Tadabase offers several types of page rules:

1. Access Rules

Control who can access a page based on conditions:

• Allow or deny access
• Evaluated before page loads
• Can redirect to another page if denied
• Show custom error messages

2. Redirect Rules

Automatically redirect users to different pages:

• Based on user attributes
• Based on data conditions
• Conditional routing
• Dynamic navigation

3. Display Rules

Control what's displayed on the page:

• Show/hide components conditionally
• Change page elements based on user
• Dynamic page content

4. Data Filter Rules

Filter data dynamically based on user:

• Show different data to different users
• Based on relationships
• Based on user attributes

Page rules are configured in the Page Builder.

How to Create a Page Rule

1. Go to Page Builder
2. Select a page
3. Click Page Settings (gear icon)
4. Go to Page Rules tab
5. Click "Add Rule"
6. Configure the rule:
   • Rule type (Access, Redirect, etc.)
   • Conditions
   • Actions
7. Save

Rule Conditions

Conditions determine when the rule applies. You can use:

• User Fields - Department, Status, Custom User Fields
• Role - User's assigned role
• Connected Records - Records linked to the user
• Date/Time - Current date, time, day of week
• URL Parameters - Values passed in the URL
• Record Values - Data from the current record being viewed

Condition Operators

Operator	Description	Example
=	Equal to	Department = "Sales"
≠	Not equal to	Status ≠ "Inactive"
>	Greater than	Credits > 0
<	Less than	Days Left < 7
Contains	Contains text	Email contains "@company.com"
Is Empty	Field is blank	Manager is empty
Is Not Empty	Field has a value	Subscription is not empty

Multiple Conditions

You can combine multiple conditions:

• AND - All conditions must be true
• OR - At least one condition must be true

Example: Complex condition

(Role = "Manager" AND Department = "Sales")
OR
(Role = "Admin")

This grants access to Sales Managers or any Admin.

Access rules control whether users can view a page.

Example 1: Department-Based Access

Scenario: Only Sales department can access the Sales Dashboard

1. Create page rule on "Sales Dashboard" page
2. Rule Type: Access Rule
3. Condition: Logged In User's Department = "Sales"
4. Action if condition fails: Redirect to "Dashboard" page
5. Error message: "Access denied. This page is for Sales department only."

Example 2: Subscription Level Access

Scenario: Premium features page only for premium subscribers

1. Create page rule on "Premium Features" page
2. Rule Type: Access Rule
3. Condition: Logged In User's Subscription Level = "Premium"
4. Action if fails: Redirect to "Upgrade" page
5. Error message: "Upgrade to Premium to access this feature."

Example 3: Account Status Check

Scenario: Block inactive users from accessing any pages

1. Create page rule on all pages (or use app-level rule)
2. Rule Type: Access Rule
3. Condition: Logged In User's Account Status = "Active"
4. Action if fails: Redirect to "Account Suspended" page
5. Error message: "Your account has been suspended. Contact support."

Example 4: Manager Access to Team Data

Scenario: Managers can only access pages for their team

1. Create page rule on "Team Details" page
2. Rule Type: Access Rule
3. Condition: Page Criteria's Team Manager = Logged In User
4. Action if fails: Redirect to "Dashboard"
5. Error message: "You can only access your own team's page."

Redirect rules automatically send users to different pages based on conditions.

Example 1: Role-Based Landing Pages

Scenario: After login, different roles go to different dashboards

1. Create redirect rule on "Login Success" page
2. Multiple conditions:
   • If Role = "Admin" → Redirect to "Admin Dashboard"
   • If Role = "Manager" → Redirect to "Manager Dashboard"
   • If Role = "Employee" → Redirect to "My Tasks"
   • If Role = "Customer" → Redirect to "Customer Portal"

Example 2: Onboarding Flow

Scenario: New users must complete profile before accessing app

1. Create redirect rule on all pages (except profile page)
2. Condition: Logged In User's Profile Completed = "No"
3. Action: Redirect to "Complete Profile" page
4. User cannot access app until profile is complete

Example 3: Trial Expiration

Scenario: Redirect users whose trial has expired

1. Create redirect rule on all pages
2. Condition: Logged In User's Trial End Date < Today
3. Action: Redirect to "Subscribe Now" page
4. Prevents access until they subscribe

Example 4: Maintenance Mode

Scenario: Show maintenance page to non-admins during updates

1. Create redirect rule on all pages
2. Condition: Logged In User's Role ≠ "Admin"
3. Action: Redirect to "Maintenance" page
4. Only admins can access during maintenance

Conditional access combines multiple factors to determine permissions.

Example 1: Time-Based Access

Scenario: Employees can only access timesheets during business hours

1. Create access rule on "Timesheet" page
2. Conditions:
   • Current Time >= 8:00 AM
   • AND Current Time <= 6:00 PM
   • AND Day of Week ≠ Saturday
   • AND Day of Week ≠ Sunday
   • OR Role = "Admin" (admins can always access)
3. Action if fails: Show error "Timesheets only available during business hours"

Example 2: Geographic Access

Scenario: Regional managers only see data for their region

1. Create access rule on "Regional Reports" page
2. Condition: Page Criteria's Region = Logged In User's Region
3. Action if fails: Redirect to "Select Region" page

Example 3: Multi-Factor Conditions

Scenario: Finance pages require specific role AND approval status

1. Create access rule on "Finance Dashboard"
2. Conditions:
   • Role = "Finance" OR Role = "Admin"
   • AND Background Check = "Approved"
   • AND Training Completed = "Yes"
3. Action if fails: Redirect with appropriate message

Example 4: Progressive Access

Scenario: Users unlock features as they complete steps

1. Create access rules on various feature pages
2. Feature 1: Logged In User's Step 1 Completed = "Yes"
3. Feature 2: Step 1 AND Step 2 Completed = "Yes"
4. Feature 3: All previous steps completed
5. Gamification approach to onboarding

Control access to specific records, not just pages.

What Are Record-Level Permissions?

Record-level permissions control whether users can view or edit individual records based on conditions.

• Different from page permissions (page vs. record)
• Implemented through page rules and filters
• Often combined with ownership (covered in next article)

Example 1: View Own Records Only

Scenario: Employees see only their own expense reports

1. Create "My Expenses" page
2. Add Table Component
3. Filter: Created By = Logged In User
4. Users only see records they created

Example 2: Manager Access to Team Records

Scenario: Managers see their team's records

1. Create "Team Performance" page
2. Add Table Component
3. Filter: Employee's Manager = Logged In User
4. Managers see only their direct reports' data

Example 3: Department-Based Record Access

Scenario: Users only see records from their department

1. Add Table Component
2. Filter: Department = Logged In User's Department
3. Complete data isolation by department

Example 4: Edit Permissions Based on Status

Scenario: Users can only edit draft records, not submitted ones

1. Create Form Component for editing
2. Add Display Rule on form
3. Show form only if: Record Status = "Draft"
4. If status is "Submitted", show read-only details instead

Ownership is a specific type of record-level permission that's so common it deserves special attention. (We'll cover this in depth in Article 6, but here's an introduction.)

What Is Ownership?

Ownership links a record to a specific user, giving that user special permissions for that record.

• Owner can view the record
• Owner can edit the record
• Owner might have delete permissions
• Non-owners cannot see or edit (unless they're admins)

Implementing Basic Ownership

1. Add a Connection Field to your table
2. Connect to Users table
3. Name it "Owner" or "Created By"
4. Enable "Auto-fill with logged in user"
5. When users create records, they're automatically set as owner

Filtering by Ownership

1. Add Table Component
2. Add Filter: Owner = Logged In User
3. Users only see their own records

Example: Task Management

• My Tasks page - Filter: Assigned To = Logged In User
• Created by Me page - Filter: Created By = Logged In User
• All Tasks page - Only accessible to Managers and Admins

We'll explore ownership in much greater detail in Article 6.

The most powerful security comes from combining roles with page rules.

Layered Security Approach

1. First Layer: Roles - Broad access categories
2. Second Layer: Page Rules - Conditional refinements
3. Third Layer: Component Permissions - Fine-grained control
4. Fourth Layer: Field Permissions - Specific data access

Example: HR System

Roles

• HR Admin
• HR Staff
• Manager
• Employee

Page: Employee Records

Role Permission: HR Admin, HR Staff, Manager

Page Rules:

• If Role = Manager: Filter to show only direct reports
• If Department = "Finance": Can see salary fields
• If Department ≠ "Finance": Salary fields hidden

Result

• HR Admin sees all employees, all fields
• HR Staff (Finance) sees all employees, including salaries
• HR Staff (Other) sees all employees, no salaries
• Managers see only their team, no salaries
• Employees cannot access this page at all

Example: Project Portal

Roles

• Admin
• Project Manager
• Team Member
• Client

Page: Project Details

Role Permission: All roles

Page Rules:

• If Role = Admin: Full access (no restrictions)
• If Role = Project Manager: Access only if Project Manager = Logged In User
• If Role = Team Member: Access only if Team includes Logged In User
• If Role = Client: Access only if Client = Logged In User

Component Visibility

• Budget section: Visible to Admin, PM only
• Internal notes: Visible to Admin, PM, Team only (not Client)
• Client files: Visible to all roles

Result

• Each user sees only projects they're involved with
• Different users see different information on the same project
• Secure multi-party collaboration

Page rules affect navigation - users only see links to pages they can access.

How Navigation Works with Page Rules

• Menu items automatically hide if user can't access the page
• Page rules are evaluated for each menu item
• Navigation adapts to each user's permissions
• Creates personalized experience

Example: Role-Based Menu

Menu items visible to different roles:

Menu Item	Admin	Manager	Employee	Customer
Dashboard	✓	✓	✓	✓
My Work	✓	✓	✓	-
Team Dashboard	✓	✓	-	-
Reports	✓	✓	-	-
My Orders	-	-	-	✓
User Management	✓	-	-	-
Settings	✓	-	-	-

Each user sees a clean menu with only the items they can access.

Here are sophisticated real-world implementations:

Example 1: Multi-Tenant Data Isolation

Scenario: SaaS app with complete data isolation between companies

1. Users table has "Company" connection field
2. All data tables have "Company" connection field
3. Page rule on ALL pages:
   • Condition: Page Criteria's Company = Logged In User's Company
   • OR: Role = "Super Admin" (can see all companies)
4. Every page automatically filters to user's company
5. Complete isolation between tenants

Example 2: Approval Workflow with Permissions

Scenario: Expense approval with different permissions per stage

Expense Status States

• Draft
• Submitted
• Manager Approved
• Finance Approved
• Paid
• Rejected

Page Rules on Expense Details Page

• Edit Button: Show if Status = "Draft" AND Owner = Logged In User
• Submit Button: Show if Status = "Draft" AND Owner = Logged In User
• Manager Approve Button: Show if Status = "Submitted" AND Employee's Manager = Logged In User
• Finance Approve Button: Show if Status = "Manager Approved" AND Role = "Finance"
• Mark Paid Button: Show if Status = "Finance Approved" AND Role = "Finance"

Result

• Each user sees only appropriate actions
• Workflow enforced through permissions
• Status progression controlled

Example 3: Hierarchical Organization Access

Scenario: Users can see data for their level and below in org chart

1. Users table has "Manager" field (connection to Users)
2. Creates hierarchical structure
3. Page rule filters:
   • Show records where Employee = Logged In User
   • OR Employee's Manager = Logged In User
   • OR Employee's Manager's Manager = Logged In User (for directors)
4. Each level sees their branch of the organization

Example 4: Educational Platform with Progressive Unlock

Scenario: Courses unlock as students complete prerequisites

1. Courses table has "Prerequisites" field (connection to Courses)
2. Users have "Completed Courses" field (connection to Courses)
3. Page rule on Course Detail pages:
   • Access granted if: Course's Prerequisites are ALL in User's Completed Courses
   • OR: Role = "Admin" or "Instructor"
4. Students can only access courses they're ready for
5. Enforces learning path

Page rules require thorough testing because they're dynamic.

Testing Strategy

1. Create Test Users with Different Attributes
   • Different roles
   • Different departments
   • Different status values
   • Different relationships (manager, team member, etc.)
2. Test Each Condition Path
   • When condition is true
   • When condition is false
   • When multiple conditions combine
3. Test Edge Cases
   • Empty/null values
   • Multiple relationships
   • Boundary conditions
4. Test Redirects
   • Do redirects work correctly?
   • Are error messages clear?
   • Can users escape redirect loops?

Common Testing Scenarios

Scenario 1: Access Denied

1. Create user who should NOT have access
2. Try to access protected page
3. Verify proper redirect or error
4. Verify page doesn't appear in navigation

Scenario 2: Conditional Access Granted

1. Create user who SHOULD have access
2. Verify they can access the page
3. Verify correct data is displayed
4. Verify correct components are visible

Scenario 3: Attribute Change

1. User initially has access
2. Change user attribute (department, role, etc.)
3. Verify access changes accordingly
4. Test immediately (cache issues?)

Scenario 4: Record-Level Access

1. Create records owned by different users
2. Log in as each user
3. Verify each sees only appropriate records
4. Try to access other users' records directly via URL

Follow these guidelines for effective page rules:

1. Start Simple

• Begin with role-based permissions
• Add page rules only when needed
• Don't over-complicate initially
• Iterate based on real needs

2. Document Complex Rules

• Comment why each rule exists
• Document expected behavior
• Create flow diagrams for complex scenarios
• Keep documentation updated

3. Avoid Redirect Loops

• Ensure there's always an accessible page
• Test redirect chains carefully
• Provide fallback pages
• Consider default landing pages

4. Provide Clear Error Messages

• Tell users WHY they can't access
• Provide next steps ("Contact your manager")
• Use friendly, non-technical language
• Don't expose security details

5. Optimize Performance

• Page rules are evaluated on every page load
• Keep conditions simple
• Avoid complex calculations in rules
• Use indexed fields in conditions

6. Maintain Consistency

• Use similar logic across pages
• Standardize condition patterns
• Reuse successful patterns
• Create rule templates

7. Plan for Exceptions

• Always allow admin override
• Consider emergency access
• Plan for null/empty values
• Handle edge cases gracefully

8. Test Thoroughly

• Test every condition path
• Test with real user scenarios
• Test after every change
• Have others test (fresh perspective)

In this article, you learned:

• What page rules are - Dynamic, conditional access control
• Types of page rules - Access, redirect, display, and filter rules
• Creating page rules - How to configure conditions and actions
• Access rules - Controlling who can view pages
• Redirect rules - Routing users dynamically
• Conditional access - Complex, multi-factor permissions
• Record-level permissions - Controlling access to individual records
• Owner-based access - Permissions based on record ownership
• Combining approaches - Using roles and page rules together
• Testing and best practices - Ensuring rules work correctly

Page rules transform static role-based permissions into dynamic, context-aware security. Combined with roles, they enable you to build sophisticated access control that adapts to your exact business requirements.

In the next article, you'll learn about user components - building the interfaces users interact with for login, signup, profiles, and authentication.

Hands-On Exercise (To Be Added)

Exercise placeholders will include practical activities such as:

• Creating access rules based on user departments
• Setting up redirect rules for different roles
• Implementing record-level permissions with filters
• Creating conditional access based on subscription level
• Testing page rules with different user scenarios
• Building a hierarchical access system

Knowledge Check (To Be Added)

Quiz questions will test understanding of:

• Difference between page rules and role permissions
• When to use page rules vs. roles
• How to create conditional access rules
• Record-level vs. page-level permissions
• Best practices for page rules
• Testing strategies for dynamic permissions