Role-based permissions
Control page, action, data, faculty, department, campus, and workflow visibility according to approved profiles.
Shared governance capability
Put scheduling requests in the right hands, in the right order.
Workflow and role-based access control add governance across the Schedulers suite. They determine who can see information, submit a request, review it, approve it, apply it, and receive confirmation.
- Institution-defined approval paths
- Role-appropriate access and visibility
- Status, notification, and audit history
Selected schools, universities, and organizations working with White Mountain Technologies.
Overview
Shared governance—not a separate scheduling engine
Role-based access control is a shared capability across the product family, not a standalone scheduling module. It gives instructors, departments, deans, registrar teams, administrators, and other users the authority appropriate to their responsibilities.
Workflow coordinates the institutional decision path. A supported example allows an instructor to request a complete day/time change for a course section or request a make-up session. The Dean or Department Chair reviews the request before it reaches the Central Registrar for final application.
Capabilities
What Workflow and Role-Based Access Control brings into one controlled process
Workflow and role-based access control connect permissions, request types, institutional approvals, status, notification, application, and audit history across the existing Schedulers modules.
Day/time change requests
Allow an instructor to request a complete change to the scheduled day and time of an assigned course section.
Make-up session requests
Allow an instructor to submit a required make-up-session time for review and application.
Multi-stage approval
Route requests to the Dean or Department Chair and then to the Central Registrar, or another configured institutional path.
Status and notifications
Show the request state and send messages when items are submitted, returned, approved, rejected, applied, or confirmed.
Auditability
Retain the request, comments, decisions, timestamps, responsible users, and final application outcome.
How it works
From a role-appropriate request to an authorized scheduling change
The institution defines who may initiate each request, which academic approvals are required, who applies the approved change, and how every participant is informed.
- 01
Submit
An authorized user creates a request with the required scheduling context and proposed change.
- 02
Review
The responsible academic approver evaluates, returns, approves, rejects, or escalates the request.
- 03
Apply
The Central Registrar or configured operational role applies the approved request to the official schedule.
- 04
Confirm
The system updates status and notifies all configured participants that the action has been completed.
Operational value
Operational value for distributed scheduling governance
For instructors
A visible, documented request path instead of disconnected email and verbal coordination.
For deans and chairs
Clear authority to review academic scheduling changes affecting their area.
For central registrars
Final control over changes to the official institutional schedule.
For audit and leadership
Traceable decisions, responsibilities, turnaround, and policy adherence.
Implementation focus
Map authority and responsibility before configuring the workflow
A workflow succeeds when it reflects actual institutional accountability. Roles, approval stages, delegation, exceptions, and the point at which a change becomes official must be explicit.
Role and visibility model
Define instructors, department chairs, deans, registrars, schedulers, administrators, and other roles—including what each may view, submit, review, approve, apply, or report.
Request and approval design
Specify day/time changes, make-up sessions, supporting information, validation rules, approval stages, rejection or return paths, escalation, and delegated authority.
Status, notification, and audit
Agree status names, recipients, reminders, confirmation messages, timestamps, reason capture, retained history, and the reports needed for operational and governance review.
Scheduling principle
Rules remain institutional. Results remain reviewable.
Workflow and RBAC do not generate schedules. They protect institutional authority around scheduling actions, ensuring that approved changes are visible, traceable, and applied only by the roles authorized to do so.
Questions
Frequently asked questions
Is RBAC a separate UniversiTools module?
No. Role-based access control is a shared capability that enriches the existing modules and controls what each user can see and do.
Which scheduling requests are supported?
The workflow can support institution-defined requests. The current design includes complete course-section day/time changes and make-up-session requests.
Who approves an instructor request?
A supported path routes the request to the Dean or Department Chair before it reaches the Central Registrar for final application.
Can a request be returned or rejected?
Yes. Workflow actions can include approval, rejection, return for correction, escalation, and final application, depending on the configured process.
Are users notified after the change is applied?
Yes. The system can send confirmation to all configured participants and retain the final request status.
Next step
See Workflow and Role-Based Access Control in the context of your institution
A focused demonstration can use your instructor, chair, dean, registrar, and scheduling roles; request types; approval stages; notifications; and audit requirements to show the governance flow end to end.