User Types & Roles

Every person in FullFabric has a profile — a single identity that carries one or more roles. Roles define what type of user you are (staff member, student, applicant, etc.) and determine what you can access. A single profile can hold multiple roles simultaneously — for example, someone can be both a staff member and a lecturer.

User Types

FullFabric has two broad categories of users: institutional users who manage the platform, and lifecycle users who progress through an educational journey.

Institutional Users

Type	Description
Admin	Full system access. Can manage settings, roles, and all platform features.
Staff	Institutional employees with access scoped by their substate (e.g., admissions, academic, finance).
Lecturer	Teaching staff who manage sessions, attendance, and grades for their assigned courses.

Lifecycle Users

Type	Description
Prospect	Someone who has expressed interest but has not started an application.
Applicant	Someone who has started or submitted an application.
Student	An enrolled learner, actively attending a programme.
Alumnus	Someone who has graduated or completed their programme.
Contact	An external representative — a parent, employer, or agent associated with another profile.

Every profile also has a base User role that tracks the account's system status (active, suspended, inactive, etc.).

The Role Model

Roles in FullFabric follow a state::substate pattern. The state is the broad user type, and the substate provides further specificity.

Examples

Role	State	Substate	Meaning
admin::support	admin	support	Administrator with support responsibilities
staff::admissions	staff	admissions	Admissions office staff
staff::finance	staff	finance	Finance department staff
lecturer::active	lecturer	active	Active teaching staff
student::enrolled	student	enrolled	Currently enrolled student
applicant::submitted	applicant	submitted	Application has been submitted
prospect::new	prospect	new	New inquiry, not yet engaged
user::active	user	active	Account is active and verified

Staff Substates

Staff members can have these substates, which control which features they can access:

• support — General support and administration
• academic — Academic programme management
• finance — Financial operations and billing
• admissions — Application processing and admissions
• marketing — Campaigns, events, and outreach
• careers — Career services
• affairs — Student affairs

Institutions can also create custom roles with a curated set of features, beyond these standard substates.

Multiple Roles

A profile can hold multiple roles at the same time. For example:

• A staff member who also lectures would have both staff::admissions and lecturer::active roles.
• A student enrolled in two programmes would have two student::enrolled roles, each in a different context (programme/class).
• A prospect who starts an application transitions from prospect to applicant by gaining a new role.

Role Contexts

Each role is bound to a context — the institutional entity it belongs to:

• Institution — Institution-wide roles (admin, staff)
• Programme / Class — Roles tied to a specific programme or class (student, applicant)
• Course / Subject — Roles tied to specific courses (lecturer)

Profile Lifecycle

Every new profile starts as user::inactive. The typical lifecycle is:

stateDiagram-v2
    [*] --> user_inactive: Account created
    user_inactive --> user_active: Email verified
    user_active --> user_suspended: Admin suspends
    user_suspended --> user_active: Admin reactivates
    user_active --> user_forgotten: GDPR forget request
    user_active --> user_deleted: Admin deletes

    state "user::inactive" as user_inactive
    state "user::active" as user_active
    state "user::suspended" as user_suspended
    state "user::forgotten" as user_forgotten
    state "user::deleted" as user_deleted

State	Description
user::inactive	Account created but email not yet verified. Cannot log in.
user::active	Verified and active. Full access based on other roles.
user::suspended	Temporarily disabled by an administrator. Cannot log in.
user::forgotten	GDPR "right to be forgotten" applied. Personal data anonymized.
user::deleted	Permanently removed by an administrator.

Lifecycle Transitions

In addition to the base user state, lifecycle users (prospects, applicants, students, alumni) progress through their own state machines. These transitions are configurable per institution via the Lifecycle engine and can be customized to match each institution's enrollment process.

For Administrators

Managing Roles

• Adding roles: Roles are typically added through the platform's profile management UI or via automated workflows (e.g., admitting an applicant adds a student::enrolled role).
• Custom roles: Go to Settings > Authorization to create custom staff roles with specific feature permissions.
• Data access scopes: Staff roles can be further restricted by assigning data access scopes that limit which programmes and classes the staff member can see.

Role and Feature Relationship

Each role maps to a set of features (permissions). Admin users automatically have access to all features. For staff and other roles, the available features are determined by the role's configuration. See Features & Permissions for details.