Users and Access Assignment

Epic summary

The Users and Access Assignment workspace gives people access to MedCES without giving them more authority than their work requires.

It manages tenant membership, core roles, organisational scope, functional roles, validity, approval, suspension, and access review. Faculty designation and appointments such as HOD remain separate records.

The application-wide rules are defined in Roles and Access.

Before you start

The tenant must exist before a user can become a member.
An institute, department, or unit must exist before access can be granted at that scope.
The person granting access must be authorised to manage the selected core or functional role and scope.
Faculty and student identities may be connected before all academic assignments exist, but those users receive only the access supported by their current records.

Actors and access

Core or functional role	Access in this epic
Platform Admin	Creates the bootstrap Tenant Admin and manages platform administrator grants
Tenant Admin	Manages tenant membership, tenant labels, and authorised grants within the tenant
Institute Admin	Manages institute membership and authorised institute, department, and unit grants
Department Admin	Views department access and manages permitted department or unit assignments
Unit Admin	Views access for their unit; cannot grant broader access
Auditor role	Reviews grants, approvals, access use, and revocations without changing them

What the user does

Screen 1: User Directory

The user selects a tenant or institute and can search by name, identifier, email, membership status, core role, functional role, department, unit, or expiry date.

Each result shows:

identity and membership status;
core roles and their scopes;
functional roles;
faculty designation or student status where applicable;
access start and end dates;
warnings for access that is expired, suspended, duplicated, or due for review.

Screen 2: Invite or Connect User

Field	Required	Meaning and validation
Person or email	Yes	Connect an existing identity or send an invitation; duplicate identities are flagged
Tenant	Yes	Tenant receiving the membership
Institute	Conditional	Required when the person will work in one institute
Membership type	Yes	Administrator, employee, faculty, student, service account, or another supported type
Start and end dates	Yes/No	Start is required; end is optional unless the engagement is temporary
Invitation message	No	Plain-language message shown to the recipient

Creating membership does not automatically grant a role.

Screen 3: Assign Core Role

Field	Required	Meaning and validation
User	Yes	Active or invited tenant member
Role	Yes	One of the seven fixed core roles
Scope	Yes	Platform, tenant, institute, department, or unit as allowed for the role
Valid from and valid to	Yes/No	Defines when the grant is active
Reason	Yes	Business reason for the grant
Approver	Conditional	Required where the grant policy uses approval

The screen explains the scope before submission. It must not use vague text such as “full access.”

Screen 4: Assign Functional Role

The administrator selects a functional role such as Admission Officer, Academic Registrar, Facilities Officer, Curriculum Committee Member, Course Coordinator, Attendance Approver, or Auditor.

The screen shows:

the capabilities included;
the organisational scope;
an optional programme, course, cycle, cohort, posting, or other target;
validity dates;
conflicts or missing prerequisites;
required approval.

A functional role can be granted without making the user an Institute Admin.

Screen 5: Effective Access Review

This screen answers four questions in plain language:

What can the user do?
Where can they do it?
Why do they have that access?
When will the access end?

It shows the core role or functional role, scope, assignments, conditions, and source approval behind every capability.

Screen 6: Suspend, Revoke, or Amend

The administrator selects the exact membership or role grant being changed. They enter the effective time, reason, evidence, and whether active sessions should be ended immediately.

Ending one grant does not remove unrelated access held by the same user.

Screen 7: Access History

The history shows invitations, grants, approvals, rejected requests, label changes, support access, reviews, suspensions, expiries, and revocations. History is read-only.

Worked example: HOD of General Medicine

Dr Sharma is a Professor and has been appointed HOD of General Medicine.

The administrator records:

Tenant membership: Active
Faculty role: Institute A
Department Admin role: General Medicine
Designation: Professor
Appointment: Head of Department, General Medicine

The designation and appointment describe who Dr Sharma is. The Department Admin grant provides the permitted department administration. Faculty teaching and assessment actions still depend on Dr Sharma’s academic assignments.

Use case 1: Invite a tenant member

As a Tenant Admin
I want to invite or connect a user without granting broad access
So that identity and membership are established before roles are assigned.

Acceptance criteria

Existing identities are reused rather than duplicated.
Membership is created for one tenant with clear validity and status.
No working capability is created merely by adding membership.
The invitation and acceptance history are recorded.

Use case 2: Grant a scoped administrator role

As an Institute Admin authorised to manage department access
I want to grant Department Admin at one department
So that the user can administer that department without accessing sibling departments.

Acceptance criteria

Only eligible scope types can be selected for the role.
The granting user cannot select a scope outside their own authority.
The grant records dates, reason, approver, and source.
Effective Access Review shows the exact descendant scope and excluded sibling departments.

Use case 3: Assign operational work without administrator access

As an Institute Admin authorised to manage admission access
I want to assign the Admission Officer role
So that the employee can perform admission work without becoming an Institute Admin.

Acceptance criteria

The functional role lists its included capabilities before assignment.
Access is restricted to the selected institute and, where applicable, cycle or work queue.
Unrelated Setup, curriculum, attendance, and competency permissions are not granted.
Expiry automatically removes the functional capabilities.

Use case 4: Explain a user’s effective access

As a user with the Auditor functional role
I want to see why a user can perform an action
So that access can be reviewed without guessing from job titles.

Acceptance criteria

Each capability shows its core or functional role source.
Scope, descendant rules, conditions, validity, and approval are visible.
Denied actions show the missing core role, functional role, assignment, or record-state condition.
The review does not expose data outside the auditor’s own scope.

Use case 5: End access safely

As a Tenant Admin
I want to suspend or revoke one access grant
So that new work stops while completed work and audit history remain intact.

Acceptance criteria

The administrator selects the exact grant and effective time.
Immediate suspension ends affected sessions or invalidates permission caches.
Historical actions continue to show the user and access source valid at that time.
Other active grants remain unchanged.

Business rules

Membership and permission are separate records.
A user may have multiple core and functional roles at different scopes.
Role codes are fixed; tenant labels affect display only.
The granting user cannot grant authority they do not possess.
A designation or appointment never silently creates a role grant.
Duplicate active grants with the same user, role, scope, and validity are rejected.
Overlapping grants that produce the same access are shown for review.
Platform support access to tenant data is temporary, reason-based, approved where required, and audited.
Records are ended or revoked, not physically deleted.

Technical design

Conceptual schema

Record	Important fields
`identity.user`	identity, display name, authentication status
`iam.tenant_membership`	`user_id`, `tenant_id`, membership type, validity, status
`iam.role_definition`	stable role code, allowed scope types, status
`iam.role_label_override`	`tenant_id`, role code, display label
`iam.role_grant`	user, role, scope entity, validity, reason, approval, status
`iam.functional_role_definition`	stable functional role code, label, allowed target types
`iam.functional_role_grant`	user, functional role, scope, target, validity, approval, status
`iam.access_review`	subject user, reviewer, due date, decision, findings
`iam.access_event`	actor, subject, action, before, after, reason, timestamp

Process-layer responsibilities

Reuse an existing identity safely when an invited email or identifier already exists.
Validate tenant membership before accepting a tenant-owned grant.
Validate that the role supports the selected scope type.
Verify that the granting user can manage the requested authority.
Calculate descendant scope only across permitted hierarchy relationships.
Combine role and functional capabilities without broadening either grant’s scope.
Consult current academic or operational assignments for record-level actions.
Expire grants automatically and invalidate affected access promptly.
Provide a human-readable explanation for allowed and denied actions.
Write an immutable access event for every material change.

Success outcome

Every user has only the access needed for their current work, and an authorised reviewer can explain exactly where that access came from.