Understanding Navigation Visibility and Role-Based Access Control (RBAC)

General For All Users User Management
Last updated: January 26, 2026 β€’ Version: 1.0

Understanding Navigation Visibility and Role-Based Access Control (RBAC)

Learn why different users see different menu items in MangoApps. This article explains the three factors that control navigation visibility: User Role Level, System Modules, and Permissions (RBAC). Understand how to configure access and troubleshoot when users can’t see expected features.

Overview

One of the most common questions we receive is: β€œWhy can some people see certain items in the navigation and others can’t?”

MangoApps uses a sophisticated Role-Based Access Control (RBAC) system combined with feature toggles to ensure users only see the features they need and have permission to use. This creates a cleaner, more focused experience while maintaining security.

The Three Factors That Control Navigation Visibility

Navigation visibility is determined by three factors that work together:

graph TD A[User Views Navigation] --> B{Factor 1: Role Level} B -->|Manager or Above| C{Factor 2: System Module Enabled?} B -->|Member| D[Simplified Employee Sidebar] C -->|No| E[Item Hidden] C -->|Yes| F{Factor 3: Has Permission?} F -->|No| E F -->|Yes| G[Item Visible]

Factor 1: User Role Level (Primary Filter)

The first check determines whether users see the full management sidebar or a simplified employee view.

Role Level What They See
Super Admin All navigation sections and items
Administrator All management sections based on their permissions
Manager Team Operations and admin sections based on permissions
Member Simplified β€œWork Hub” focused on personal tasks

Why it matters: Members (regular employees) see a streamlined interface with only the features they need for their daily workβ€”their shifts, attendance, timesheets, and profile. This prevents confusion and keeps the interface clean.


Factor 2: System Modules (Feature Toggles)

Even if a user has the right role level, menu items only appear if the corresponding System Module is enabled for the business.

System Module Controls Visibility Of
Shifts & Scheduling Shift Scheduler, Team Calendar, Shift Coverage, Schedule Requests
Time & Attendance Attendance Tracker, Attendance Insights, Clock In/Out
Leave Management Time Off & Requests, Leave Management, Holiday Calendar
Timesheets & Payroll Timesheet Manager, Payroll, Timesheet Approvals
Skills & Certifications Skills & Certifications, Skill Insights, Job Functions
Compensation Management Compensation Management section

Why it matters: Businesses only see features they’ve enabled. A business that doesn’t use scheduling won’t see scheduling-related menu items, keeping their interface relevant.

Where to configure: Organization Settings β†’ System Modules


Factor 3: Permissions (RBAC)

The final check uses Role-Based Access Control (RBAC) to verify the user has explicit permission to access each feature.

How Role-Based Access Control (RBAC) Works

MangoApps implements RBAC through Organizational Roles and Permissions. Here’s how the system determines access:

The Permission Check Flow

sequenceDiagram participant User participant System participant OrgRole as Organizational Role participant Permissions User->>System: Requests access to feature System->>System: Check if Super Admin alt Is Super Admin System->>User: βœ… Access Granted (all permissions) else Not Super Admin System->>OrgRole: Get user's organizational role OrgRole->>Permissions: Check feature permission alt Has Permission Permissions->>User: βœ… Access Granted else No Permission Permissions->>User: ❌ Access Denied (item hidden) end end

Understanding the can_access Check

Behind the scenes, MangoApps uses a permission check called can_access(feature_key, action) that:

  1. Checks if user is Super Admin β†’ If yes, grants access to everything
  2. Gets the user’s Organizational Role β†’ The role assigned in their profile
  3. Checks role permissions β†’ Looks up if that role has the specific permission enabled
  4. Returns result β†’ Either shows or hides the menu item

Permission Structure

Each permission has two components:

Component Description Example
Feature Key The area or feature being accessed shifts, attendance, compliance
Action The level of access view (read-only) or manage (full control)

Examples:

  • can_access('shifts', 'manage') β†’ Can the user create/edit/delete shifts?
  • can_access('attendance', 'view') β†’ Can the user view attendance records?
  • can_access('compliance', 'manage') β†’ Can the user manage labor compliance settings?

Available Feature Keys and What They Control

Feature Key View Permission Shows Manage Permission Shows
shifts View schedules Shift Scheduler, Team Calendar, Team Availability
attendance View attendance Attendance Tracker, Absence Reports
timesheets View timesheets Timesheet Manager
leave_requests View leave requests Leave Management (if has direct reports)
payroll View payroll Payroll section
certifications My Skills & Certifications Skills & Certifications management
compliance β€” Labor Compliance section
workforce_intelligence BI Dashboard, Performance Scores Scoring & Logic configuration
performance_scores Performance Scores β€”
system_configurations β€” Administration section
organization_settings β€” Organization Settings section
settings β€” Business SuperAdmin section

How Permissions Are Assigned

Permissions flow through the following hierarchy:

graph TD subgraph "Permission Sources" A[Default Roles] --> C[User's Organizational Role] B[Custom Roles] --> C end subgraph "Role Configuration" C --> D[Individual Permissions] D --> E{Permission Enabled?} end E -->|Yes| F[βœ… User Can Access Feature] E -->|No| G[❌ Feature Hidden]

Default Roles and Their Permissions

MangoApps comes with four Default Roles that have pre-configured permissions:

Default Role Typical Permissions
Super Admin All permissions (cannot be modified)
Administrator Full access to organization settings, user management, and all operational features
Manager Team operations, analytics, performance scores, and EPMS features for their team
Member Self-service only: own shifts, attendance, timesheets, and profile

Custom Roles

Administrators can create Custom Roles with specific permission combinations. For example:

  • HR Coordinator: Can manage users and leave requests but not schedules
  • Compliance Officer: Can manage compliance but not other admin functions
  • Shift Lead: Can view schedules but not manage them

Where to configure: Administration β†’ Roles & Permissions


Putting It All Together: A Real Example

Let’s trace why a Supervisor might see certain menu items:

What the Supervisor Sees

Navigation Item Visible? Why?
Work Hub βœ… Yes All users see personal work items
Team Operations βœ… Yes Role is Manager level
Shift Scheduler βœ… Yes Shifts module enabled + has shifts.manage permission
Attendance Tracker βœ… Yes Attendance module enabled + has attendance.manage permission
Payroll ❌ No Doesn’t have payroll.manage permission
Labor Compliance ❌ No Doesn’t have compliance.manage permission
Organization Settings ❌ No Doesn’t have organization_settings.manage permission

The Decision Process

Supervisor logs in
β”‚
β”œβ”€ Is Manager or above? β†’ YES (Manager level)
β”‚   β”‚
β”‚   β”œβ”€ Team Operations section:
β”‚   β”‚   β”œβ”€ Shifts module enabled? β†’ YES
β”‚   β”‚   β”‚   └─ Has shifts.manage? β†’ YES β†’ Show Shift Scheduler βœ…
β”‚   β”‚   β”‚
β”‚   β”‚   β”œβ”€ Attendance module enabled? β†’ YES
β”‚   β”‚   β”‚   └─ Has attendance.manage? β†’ YES β†’ Show Attendance Tracker βœ…
β”‚   β”‚   β”‚
β”‚   β”‚   └─ Timesheets module enabled? β†’ YES
β”‚   β”‚       └─ Has payroll.manage? β†’ NO β†’ Hide Payroll ❌
β”‚   β”‚
β”‚   └─ Organization Settings section:
β”‚       └─ Has organization_settings.manage? β†’ NO β†’ Hide entire section ❌

Troubleshooting: β€œWhy Can’t I See…?”

Problem: User can’t see a menu item they need

Step 1: Check System Module

  • Is the feature’s System Module enabled for the business?
  • Navigate to: Organization Settings β†’ System Modules

Step 2: Check User’s Role Level

  • Is the user at least a Manager? Members see a simplified sidebar.
  • Navigate to: User’s profile β†’ Role field

Step 3: Check Role Permissions

  • Does their Organizational Role have the required permission?
  • Navigate to: Administration β†’ Roles & Permissions β†’ Find their role β†’ Check permissions

Problem: User sees too many menu items

Solution: Adjust their Organizational Role’s permissions or assign them to a more restricted custom role.

Problem: Everyone in the company can’t see a feature

Solution: The System Module is likely disabled. Enable it in Organization Settings β†’ System Modules.


Configuration Quick Reference

What to Configure Where to Find It Who Can Change It
User’s Role User Profile β†’ Role dropdown Administrators
Role Permissions Administration β†’ Roles & Permissions Administrators
System Modules Organization Settings β†’ System Modules Super Admins
Custom Roles Administration β†’ Roles & Permissions β†’ New Custom Role Administrators
Marketplace Apps Organization Settings β†’ AI Agents & Apps Administrators

Best Practices

For Administrators

  1. Start with Default Roles: Use the built-in Default Roles before creating custom ones
  2. Create Purpose-Specific Custom Roles: If you need fine-grained control, create custom roles for specific job functions
  3. Audit Regularly: Review who has access to what quarterly
  4. Document Your Role Structure: Keep notes on why each custom role exists

For Support Teams

  1. Check the Three Factors: When troubleshooting, always check Role Level β†’ System Module β†’ Permission
  2. Use the Permission Matrix: Reference the Roles & Permissions page to see what each role can access
  3. Verify User’s Organizational Role: The role shown in their profile determines their permissions

This article should be updated when:

  1. New permission feature keys are added
  2. The RBAC system is modified
  3. New System Modules are added
  4. The sidebar structure changes significantly
  5. New Default Roles are added or existing ones modified
  6. The permission inheritance model changes