Module-Level Role-Based Access Control (RBAC)

Module-level RBAC provides default permissions for all components in a module. It sits between environment-level role defaults and component-level permissions. Creators use it to set efficient security across entire modules.

Module-level RBAC controls end-user access to modules by setting default permissions for each Express Role at the module level.

How Module-Level RBAC Works

Module-level RBAC behavior differs depending on whether the Customize RBAC for This Module toggle is on or off. The system computes effective permissions from the inheritance chain.

When RBAC Is Enabled

When Customize RBAC for This Module is enabled, the system activates the following granular permission controls:

• Explicit permissions can be set for each Express Role.
• Components inherit the module's permission settings by default.
• Components can override module permissions individually.
• The system computes effective permissions by evaluating the permission hierarchy.

Permission Hierarchy:

none (lowest) < read < write (highest)

When an end-user has multiple roles, the highest permission level wins.

When RBAC Is Disabled

When Customize RBAC for This Module is OFF, the following occurs:

• The permissions table is disabled.
• End-users with the NoAccess role are restricted.
• Anonymous access is automatically disabled.
• All other authenticated roles automatically get Write access to the module and its components.
• Component-level permissions are ignored.

Critical Distinction: Disabling RBAC grants Write access to all authenticated roles except NoAccess, instead of requiring explicit permission grants. Anonymous access is disabled.

Effective Permissions

Effective permissions are the final computed permissions after evaluating the entire inheritance chain.

The system tracks the following:

• Permission value: The actual permission level (none, read, write).
• Source: Where the permission came from. Options include:
  • Role Defaults: Inherited from the Express Role's default permission.
  • Module: Set explicitly at the module level.

Evaluation Order:

1. Admin roles: Always get Write permission.

2. NoAccess role: Always gets None permission.

3. Other roles (when Customize RBAC for This Module is enabled):

   • If the component has an explicit permission set, the component permission applies.
   • If the module has an explicit permission set, the module permission applies.
   • If the role has a default permission, the role default applies.
   • If none of the above are set, None applies.

   When Customize RBAC for This Module is disabled, all other authenticated roles automatically get Write permission.

Module RBAC Settings

To access the module settings panel, open the module in Module Builder and select Settings from the (ellipsis) Definition menu. Then select User Permissions from the left sidebar.

The following settings appear in the User Permissions section.

Customize RBAC for This Module

What it does:

• When ENABLED, the following occurs:

  • Activates the permissions table.
  • Explicit role-to-permission mappings become active.
  • Components can have field-level permissions.
  • End-users see the module based on their explicit permissions.

• When DISABLED, the following occurs:

  • Permissions table is disabled.
  • The NoAccess role is restricted.
  • Anonymous access is disabled.
  • All other authenticated roles get Write access automatically.
  • Component permissions are ignored.

Storage: Stored as module.settings.enableRbac (boolean)

Allow Access to Anonymous Users

What it does:

• Lets unauthenticated end-users access the module.
• Only works when Customize RBAC for This Module is enabled.
• When ON, this setting lets Creators set specific permissions for the Anonymous role.

Restrictions:

• Automatically disabled when Customize RBAC for This Module is set to OFF.
• Cannot be enabled without RBAC customization.

Storage: Stored as module.settings.enableAnonymous (boolean)

Permissions Table

The permissions table displays all Express Roles and their permission settings for the module.

Columns:

Permission Options:

At the module level, the following options are available:

• Inherit: Use the role's default permission from environment settings.
• No Access: Block access completely. End-users cannot see or access the module.
• Read-Only: End-users can view data but cannot edit it.
• Write: End-users have full access to view and edit data.

The Obfuscate option is available at the component level, not at the module level.

Disabled Rows:

• Locked modules: All selectors are disabled.

Enabling Module-Level RBAC

1. Open the module in Module Builder.
2. From the (ellipsis) Definition menu, select Settings.
3. In the left sidebar, select User Permissions.
4. Toggle Customize RBAC for This Module to ON. The permissions table becomes active.
5. For each Express Role, select a permission from the Permission drop-down. Options include:
   • Inherit: Use the role's default permission.
   • No Access: Block access completely.
   • Read-Only: View.
   • Write: Full access.
6. Review the Effective Permission and Inherited From columns to verify the computed result.
7. Click Save.

To grant unauthenticated access, toggle Allow Access to Anonymous Users to ON and set a permission for the Anonymous role, typically Read-Only or No Access.

Permission Inheritance Examples

The following examples show how permission levels are computed across different configurations of RBAC, role defaults, and module overrides.

Example 1: Basic Inheritance

Environment Setup:

• Role: Standard User
• Role Default Permission: Read

Module Configuration:

• Customize RBAC: OFF

Result:

• Standard User gets Write access (disabling RBAC grants Write to all authenticated roles except NoAccess).

Example 2: Module Override

Environment Setup:

• Role: Standard User
• Role Default Permission: Read

Module Configuration:

• Customize RBAC: ON
• Standard User Permission: Write

Result:

• Standard User gets Write access (module overrides role default).

Example 3: Multiple Roles

Environment Setup:

• User: Jane
• Roles: Viewer (default: Read), Editor (default: Write)

Module Configuration:

• Customize RBAC: ON
• Viewer Permission: Read
• Editor Permission: Write

Result:

• Jane gets Write access (highest permission from all roles).

Example 4: Anonymous Access

Environment Setup:

• Role: Anonymous (default: None)

Module Configuration:

• Customize RBAC: ON
• Allow Anonymous Access: ON
• Anonymous Permission: Read-Only

Result:

• Unauthenticated end-users can view the module but cannot edit.

When to Use Module-Level RBAC

Module-level RBAC is most effective when access rules are consistent across most or all components in a module. It also applies when a secure default must be established before individual fields are tuned. The following scenarios illustrate where this approach adds the most value.

All Components Should Have the Same Rules

If every field in a module should have identical access rules for each role, set it at the module level. This approach avoids configuring each component individually. For example, an employee directory module where all fields (name, email, phone) should be read-only for Standard Users and writable for HR Managers.

Establishing a Security Baseline

Set conservative defaults at the module level, then override specific components that need different permissions. For example, set the module to Read-Only for most roles, but mark a Comments field as Write for all authenticated end-users.

Building Public-Facing Modules

Enable Anonymous Access and set appropriate permissions for unauthenticated end-users. For example, a product inquiry form where anonymous end-users can submit data. Form fields are set to Write, but data tables are set to No Access so submissions cannot be viewed.

Minimal Component Overrides

If a few fields need special permissions, it is more efficient to set module defaults and override exceptions. For example, a claims form where most fields follow standard role permissions, but the SSN field must be obfuscated for certain roles.

Best Practices

The following practices reduce permission complexity and prevent unintended access.

1. Begin with Module Defaults

• Configure module-level permissions first.
• Set conservative defaults (Read-Only or No Access).
• Override at the component level for exceptions.

2. Test with Different Roles

• Create test end-user accounts with different role assignments to test each role.
• Verify that effective permissions match expectations.
• Check the Inherited From column to understand permission sources.

3. Use Inherit When Possible

• Set roles to Inherit if the environment default is correct.
• Avoid unnecessary overrides that complicate maintenance.
• Override when different behavior is needed.

4. Document Permission Decisions

• Add comments in Module Builder describing why certain roles have specific permissions.
• Maintain a permission matrix document for complex modules.
• Share with stakeholders before deployment.

5. Limit Anonymous Access

• Only enable anonymous access when absolutely necessary.
• Set Anonymous to Read-Only or No Access by default.
• Never grant Write access to Anonymous end-users for sensitive data.

6. Review Effective Permissions

• Always check the Effective Permission column after making changes.
• Verify that role hierarchy does not create unintended permissions.
• Use the lowest necessary permission level.

Common Patterns

The following patterns cover the most frequent module RBAC configurations.

Pattern 1: Public Submission Form

Use Case: Anonymous end-users can submit data, but cannot view other submissions.

Configuration:

• Customize RBAC: ON
• Allow Anonymous Access: ON
• Anonymous Permission: Write (for form fields)
• Component overrides: Set data tables to No Access for Anonymous

Pattern 2: Read-Only Reference Module

Use Case: Most end-users can view data; administrators can edit.

Configuration:

• Customize RBAC: ON
• Standard User Permission: Read-Only
• Administrator Permission: Write

Pattern 3: Progressive Disclosure

Use Case: Different roles see different levels of detail.

Configuration:

• Customize RBAC: ON
• Basic User Permission: Read-Only
• Advanced User Permission: Write
• Component overrides: Hide sensitive fields from Basic User (No Access), display for Advanced User

Pattern 4: Workflow with Stages

Use Case: End-users can edit their own submissions, managers can edit all.

Configuration:

• Customize RBAC: ON
• Submitter Permission: Write
• Manager Permission: Write
• Use Groups to control data access between submitters and managers.