1. Executive Summary

This process handles physical and temporary accommodation cases in Irshad, from student submission through medical-center review, assignment, student confirmation, and case closure.

The BPMN model uses three pools: Student, Medical center, and Irshad System. It also calls the shared send-accommodation subprocess when accommodations must be sent to recipient departments.

  • Student submits a case and may be asked to complete missing information.
  • Medical center reviews, validates, and either rejects or assigns accommodations.
  • Student can accept assigned accommodations or request another review.
  • Irshad closes inactive rejected cases after the modeled 7-day wait.

2. Process Scope and Triggers

Primary trigger

The Student pool starts at Accommodations required, then the student enters Irshad, selects the accommodations service, chooses the physical/temporary category, fills required information, uploads documents, and submits the case.

See: Student pool StartEvent_1 and tasks Activity_1aukdg5 to Activity_1aatw0o.

Cross-pool activation

Irshad receives the submitted case and forwards valid cases to the Medical center. That message starts the Medical center review flow.

See: message flows Flow_0jvxz8r and Flow_08ee312.

Process boundary

This page covers modeled behavior from submission to closure, including appeal outcomes and post-acceptance dispatch. Department-side execution after receipt is out of scope and represented through the send-accommodation subprocess.

3. Roles and Action Ownership

Role / Lane Ownership in this process
Student Submits case information and documents, responds to missing-information returns, files appeals after rejection, and makes final acceptance decisions.
Medical center - Secertary lane Performs system-facing registration tasks in Irshad (reject case in Irshad, assign accommodations in Irshad, reject appeal in Irshad, and register finalized accommodations in Irshad).
Medical center - Medical Committee lane Performs clinical/committee activities: screening, presentation, case review/discussion, assignment decision, appeal review, and finalization with response to comments.
Irshad System Validates required data, routes cases/events, records first rejection, manages event-based waits, triggers closure on timeout, and dispatches accepted accommodations to relevant departments through call activities.
Recipient departments Receive accommodation notifications through the send-accommodation subprocess and acknowledge receipt.

4. Lifecycle Phases

Phase A: Submission and intake

Student submits the case. Irshad checks required information and either returns the case to the student for completion or forwards it to the Medical center.

Phase B: Medical review and decision

Medical center screens and reviews case validity. The case is either rejected with comments (entered in Irshad) or accepted for accommodation assignment.

Phase C: Student decision loop

When accommodations are assigned, the student reviews and either accepts or requests accommodation review with comments.

Phase D: Reconsideration and final student decision

If review is requested, Medical center finalizes accommodations and sends them back. Student then performs a final accept/reject decision.

Phase E: Appeals and closure control

Rejected cases may be appealed by the student. If no appeal arrives within 7 days after rejection, Irshad closes the case. Appeal rejection also closes the case.

Phase F: Dispatch after acceptance

After accommodation acceptance, Irshad evaluates which departments need to be notified and invokes the send-accommodation subprocess for each selected path.

5. Process Map (BPMN)

BPMN Diagram Notice: This document export excludes the interactive BPMN diagram.
To view the full process map, please visit:
ba-dsa.pages.dev → Physical/Temporary Accommodation Case Process

6. Detailed Walkthrough by Pool/Lane

Step Pool/Lane Action Modeled outcome
1.0 Student Submit physical/temporary case Case sent to Irshad for required-information check.
2.0 Irshad System Check required information If incomplete, return case to student; if complete, forward to Medical center.
3.0 Medical center (Secertary + Medical Committee) Screen and validate case If invalid, reject case with comments in Irshad; if valid, present and discuss in committee.
4.0 Medical center Decide case acceptance If accepted, assign accommodations and register assignment in Irshad. If rejected, case moves to rejection event.
5.0 Student Review assigned accommodations (first decision) If accepted, proceed toward department dispatch. If not accepted, request accommodation review with comments.
6.0 Medical center Handle accommodation review request Medical center reviews request, finalizes accommodations with response to comments, and registers finalized accommodations in Irshad.
7.0 Student Review final accommodations (final decision) Student either accepts accommodations or rejects accommodations.
8.0 Student + Medical center + Irshad System Appeal branch after rejection Student may submit appeal with evidence. Medical center reviews appeal and either assigns accommodations (appeal accepted) or rejects appeal.
9.0 Irshad System Timeout and closure control If a rejected case remains without appeal for 7 days, Irshad closes the case. Appeal rejection also ends in case closure.
10.0 Irshad System + Department recipients Dispatch accepted accommodations Irshad evaluates required departments and invokes send-accommodation call activities, including housing split (male/female), registrar, food, transportation, security, academic departments, and counseling referral.

7. Appeals, Timeouts, and Closure Rules

Case rejection and appeal path

After a rejection event, the student can submit an appeal with additional evidence. Medical center processes the appeal and returns either appeal accepted or appeal rejected.

See: Event_1lwb745, Activity_0q256m1, Event_14ct1v8, Gateway_0n913vn.

7-day inactivity closure

If the case reaches rejection and no appeal is submitted within the modeled 7-day event wait, Irshad executes close-case logic and closes the case.

See: Event_1wr1kby to Activity_0emizrg to Event_005gr2w.

Boundary closure during student appeal task

The student appeal task has a boundary event named Case closed, allowing immediate termination when closure is triggered externally in the model.

See: boundary Event_1m4oy08 attached to Activity_0q256m1.

Final rejection closure

If the student rejects finalized accommodations, Irshad closes the case.

See: Event_0mj5fxz to Activity_0y3iew9 to Event_135dosy.

8. Department Dispatch Rules

Dispatch occurs only after an accommodation acceptance event is registered. Irshad then evaluates which downstream departments should receive accommodations.

Dispatch branch Modeled behavior Implementation note
Registration Call activity sends accommodations to Registrar. Calls Process_0xyvy56 (send-accommodation).
Academic accommodations Call activity sends to academic departments. Calls Process_0xyvy56.
Housing Gateway checks male/female, then calls corresponding housing activity. Both male and female housing call activities point to Process_0xyvy56.
Food / Transportation / Parking Each branch invokes a dedicated call activity. Each is modeled as a call to Process_0xyvy56.
Counseling Script task refers student to counseling unit. Modeled as script task, not call activity.

9. Inputs, Outputs, and System Artifacts

Inputs

  • Student case submission in physical/temporary category.
  • Required information fields in Irshad.
  • Supporting documents uploaded by student.
  • Appeal evidence (when appeal is submitted).
  • Medical center review and comments.

Outputs

  • Case returned for completion, rejected, accepted, or closed.
  • Assigned accommodations and finalized accommodations records.
  • Department dispatch invocations and downstream acknowledgements (via send-accommodation).

System artifacts

  • Case record state transitions (submission, rejection, appeal, closure).
  • First rejection registration in Irshad.
  • Final accept/reject decision records.
  • Dispatch branch selection artifacts for downstream departments.

10. Governance and Audit Notes

Traceability expectations

Each modeled transition should be auditable in Irshad: validation decision, rejection comments, appeal submissions, appeal outcomes, assignment/finalization, and closure path.

Modeled control points

  • Required-information validation before forwarding to Medical center.
  • Event-based waiting gates that separate mutually exclusive outcomes.
  • Explicit 7-day timeout closure on rejection-without-appeal path.
  • Two-step student acceptance logic (initial and final after review request).

Documentation boundary

This documentation reflects the modeled BPMN behavior. Department-specific operational execution after notification is outside this process page.

↑ Back to top