Features & Permissions

FullFabric controls what each user can do through a three-layer authorization system: modules determine which capabilities are available to the institution, features define specific permissions, and roles assign those features to users.

How Authorization Works

When you try to access a page or perform an action, FullFabric checks three things in sequence:

flowchart TD
    A[User tries an action] --> B{Is the module enabled?}
    B -->|No| C[403 Forbidden]
    B -->|Yes| D{Does the user's role\nhave the required feature?}
    D -->|No| C
    D -->|Yes| E{Does the resource policy\nallow this action?}
    E -->|No| C
    E -->|Yes| F[Action allowed]

1. Module check — Is the relevant module enabled for this institution?
2. Feature check — Does the user's role include the required feature?
3. Policy check — Does the specific resource policy allow this user to perform this action?

Modules

Modules are top-level capability groups that institutions can enable or disable. They control whether an entire area of the platform is available.

Examples of modules:

Module	What it enables
applics	Applications & Registrations
affairs	Academic Affairs (courses, grades, transcripts)
financial.book_keeper	Financial management (billing, payments)
campaigns	Email campaigns and marketing
events	Event management
evaluations	Application evaluations and reviews
automation	Workflow automation

If a module is disabled, none of its features are available — regardless of what roles users have. Module configuration is managed in the institution's settings.

Features

Features are named permissions that gate access to specific actions. Each feature belongs to a module and can include (depend on) other features.

Feature Naming Convention

Features follow the pattern module.feature_name:

Feature	Module	Description
applics.applications_access	Applications	View applications and submission status
applics.applications_change	Applications	Edit application forms and submissions
core.institutions.profile_access	Core	View profile information
authorization.users_change	Authorization	Manage staff roles and permissions
core.institutions.settings_api_tokens_change	Core	Create and manage API tokens
authorization.roles_change	Authorization	Create roles and assign features

Feature Dependencies

Features can include other features, forming dependency chains. When a role has a feature, it automatically inherits all included features.

For example, applications_change includes:

• applications_access (view applications)
• form_templates.forms_change (edit form templates)
• financial.book_keeper.discounts_access (view discounts)

This means granting applications_change automatically grants read access to applications, form templates, and discount information.

Roles and Feature Assignment

How Roles Map to Features

Each role (like staff::admissions) is configured with a set of features. When FullFabric checks whether a user can perform an action:

1. It determines which features are required for that action.
2. It collects all features from all of the user's roles.
3. It resolves feature dependencies (included features).
4. If any required feature is in the user's set, access is granted.

Admin Users

Admin users bypass feature checks entirely — they have access to all features. This is built into the feature resolution logic, not the role configuration.

Custom Roles

Institutions can create custom roles beyond the standard substates. For example, an "Admissions Manager" custom role might include applications_change, applications_delete, and application_templates_change, but not users_change.

Custom roles are managed in Settings > Authorization, where administrators can:

• Create new roles with a custom name
• Toggle individual features on or off for each role
• Assign the role to staff profiles

What Users Experience

Staff Members

The features assigned to your role determine which sidebar menu items you see and which actions you can perform. For example:

• A staff member with applications_access but not applications_change can view applications but not edit them.
• A staff member without events module features won't see the Events section at all.

Students, Applicants, and Other Lifecycle Users

Lifecycle users have a fixed set of features appropriate to their role. Students can view their courses and grades, applicants can access their application forms, and so on. These permissions are not configurable per user — they come from the role definition.

API Tokens

API tokens have minimal permissions. Currently, they only have core.core.files_download — enough to download files via the API, but not to access other resources.