Student enrolment BPMN example

Student enrolment turns an accepted offer into a registered student with a record, a fee plan, and working accounts. Universities map it because it compresses into a few frantic weeks each year and involves admissions, finance, registry, and IT all working the same cohort. The classic failure is evidence chasing: applicants who have not yet met their offer conditions circulate by email with no defined route back into checking.

This model uses one pool with four lanes, one exclusive gateway, and a parallel gateway pair. Two choices are worth noticing. First, the evidence chase is a proper rework loop through a message catch event, not a vague "follow up" task. Second, fee setup and record creation run in parallel, because finance and registry do not wait for each other; only IT provisioning, which needs the student record, comes after the join.

Student enrolment: BPMN 2.0 diagram

Student enrolment process modelled as a BPMN 2.0 diagram

Download .bpmn Download SVG or open it in the free BPMN viewer

Standard BPMN 2.0 interchange XML: opens in Camunda Modeler, Signavio, Bizagi, and any other compliant tool.

The process at a glance

Starts when

Offer accepted

Ends with

Student enrolled

Lanes

Admissions · Finance · Registry · IT services

Decisions

Conditions met?

How to read this diagram

Once an offer is accepted, the Admissions lane verifies the entry conditions. The gateway "Conditions met?" splits the flow: on the default No branch, admissions sends a request for the missing evidence and the process waits at the "Evidence received" message event before looping back to verification. An applicant can go round this loop as many times as it takes, but cannot proceed without passing the check.

When conditions are met, a parallel gateway forks the work: the Finance lane sets up the tuition fee plan while Registry creates the student record. Both branches meet at the joining parallel gateway, and only then does the IT lane provision the accounts through a service task. The process closes at the single "Student enrolled" end event, so a student is either fully enrolled with fees, record, and accounts in place, or still somewhere in the flow.

BPMN elements used

Element	Count	In this diagram
Start event	1	Offer accepted
End event	1	Student enrolled
Intermediate catch event	1	Evidence received
User task	2	Verify entry conditions, Set up tuition fee plan
Service task	2	Create student record, Provision IT accounts
Send task	1	Request missing evidence
Exclusive gateway	1	Conditions met?
Parallel gateway	2

View the BPMN 2.0 XML for this diagram

<?xml version="1.0" encoding="UTF-8"?>
<bpmn2:definitions xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="Definitions_1" targetNamespace="http://bpmn.io/schema/bpmn" exporter="swimdraft" exporterVersion="1.0">
  <bpmn2:collaboration id="Collaboration_1">
    <bpmn2:participant id="pool_enr" name="Student enrolment" processRef="Process_pool_enr" />
  </bpmn2:collaboration>
  <bpmn2:process id="Process_pool_enr" isExecutable="false">
    <bpmn2:laneSet id="LaneSet_pool_enr">
      <bpmn2:lane id="lane_enr_adm" name="Admissions">
        <bpmn2:flowNodeRef>start_enr</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>t_enr_verify</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>g_enr_met</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>t_enr_evidence</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>ev_enr_docs</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>g_enr_split</bpmn2:flowNodeRef>
      </bpmn2:lane>
      <bpmn2:lane id="lane_enr_fin" name="Finance">
        <bpmn2:flowNodeRef>t_enr_fees</bpmn2:flowNodeRef>
      </bpmn2:lane>
      <bpmn2:lane id="lane_enr_reg" name="Registry">
        <bpmn2:flowNodeRef>t_enr_record</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>g_enr_join</bpmn2:flowNodeRef>
      </bpmn2:lane>
      <bpmn2:lane id="lane_enr_it" name="IT services">
        <bpmn2:flowNodeRef>t_enr_it</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>end_enr_done</bpmn2:flowNodeRef>
      </bpmn2:lane>
    </bpmn2:laneSet>
    <bpmn2:startEvent id="start_enr" name="Offer accepted">
      <bpmn2:outgoing>fenr1</bpmn2:outgoing>
    </bpmn2:startEvent>
    <bpmn2:userTask id="t_enr_verify" name="Verify entry conditions">
      <bpmn2:incoming>fenr1</bpmn2:incoming>
      <bpmn2:incoming>fenr6</bpmn2:incoming>
      <bpmn2:outgoing>fenr2</bpmn2:outgoing>
    </bpmn2:userTask>
    <bpmn2:exclusiveGateway id="g_enr_met" name="Conditions met?" default="fenr4">
      <bpmn2:incoming>fenr2</bpmn2:incoming>
      <bpmn2:outgoing>fenr3</bpmn2:outgoing>
      <bpmn2:outgoing>fenr4</bpmn2:outgoing>
    </bpmn2:exclusiveGateway>
    <bpmn2:sendTask id="t_enr_evidence" name="Request missing evidence">
      <bpmn2:incoming>fenr4</bpmn2:incoming>
      <bpmn2:outgoing>fenr5</bpmn2:outgoing>
    </bpmn2:sendTask>
    <bpmn2:intermediateCatchEvent id="ev_enr_docs" name="Evidence received">
      <bpmn2:incoming>fenr5</bpmn2:incoming>
      <bpmn2:outgoing>fenr6</bpmn2:outgoing>
      <bpmn2:messageEventDefinition id="ev_enr_docs_def" />
    </bpmn2:intermediateCatchEvent>
    <bpmn2:parallelGateway id="g_enr_split">
      <bpmn2:incoming>fenr3</bpmn2:incoming>
      <bpmn2:outgoing>fenr7</bpmn2:outgoing>
      <bpmn2:outgoing>fenr8</bpmn2:outgoing>
    </bpmn2:parallelGateway>
    <bpmn2:userTask id="t_enr_fees" name="Set up tuition fee plan">
      <bpmn2:incoming>fenr7</bpmn2:incoming>
      <bpmn2:outgoing>fenr9</bpmn2:outgoing>
    </bpmn2:userTask>
    <bpmn2:serviceTask id="t_enr_record" name="Create student record">
      <bpmn2:incoming>fenr8</bpmn2:incoming>
      <bpmn2:outgoing>fenr10</bpmn2:outgoing>
    </bpmn2:serviceTask>
    <bpmn2:parallelGateway id="g_enr_join">
      <bpmn2:incoming>fenr9</bpmn2:incoming>
      <bpmn2:incoming>fenr10</bpmn2:incoming>
      <bpmn2:outgoing>fenr11</bpmn2:outgoing>
    </bpmn2:parallelGateway>
    <bpmn2:serviceTask id="t_enr_it" name="Provision IT accounts">
      <bpmn2:incoming>fenr11</bpmn2:incoming>
      <bpmn2:outgoing>fenr12</bpmn2:outgoing>
    </bpmn2:serviceTask>
    <bpmn2:endEvent id="end_enr_done" name="Student enrolled">
      <bpmn2:incoming>fenr12</bpmn2:incoming>
    </bpmn2:endEvent>
    <bpmn2:sequenceFlow id="fenr1" sourceRef="start_enr" targetRef="t_enr_verify" />
    <bpmn2:sequenceFlow id="fenr2" sourceRef="t_enr_verify" targetRef="g_enr_met" />
    <bpmn2:sequenceFlow id="fenr3" name="Yes" sourceRef="g_enr_met" targetRef="g_enr_split">
      <bpmn2:conditionExpression xsi:type="bpmn2:tFormalExpression">Yes</bpmn2:conditionExpression>
    </bpmn2:sequenceFlow>
    <bpmn2:sequenceFlow id="fenr4" name="No" sourceRef="g_enr_met" targetRef="t_enr_evidence" />
    <bpmn2:sequenceFlow id="fenr5" sourceRef="t_enr_evidence" targetRef="ev_enr_docs" />
    <bpmn2:sequenceFlow id="fenr6" sourceRef="ev_enr_docs" targetRef="t_enr_verify" />
    <bpmn2:sequenceFlow id="fenr7" sourceRef="g_enr_split" targetRef="t_enr_fees" />
    <bpmn2:sequenceFlow id="fenr8" sourceRef="g_enr_split" targetRef="t_enr_record" />
    <bpmn2:sequenceFlow id="fenr9" sourceRef="t_enr_fees" targetRef="g_enr_join" />
    <bpmn2:sequenceFlow id="fenr10" sourceRef="t_enr_record" targetRef="g_enr_join" />
    <bpmn2:sequenceFlow id="fenr11" sourceRef="g_enr_join" targetRef="t_enr_it" />
    <bpmn2:sequenceFlow id="fenr12" sourceRef="t_enr_it" targetRef="end_enr_done" />
  </bpmn2:process>
  <bpmndi:BPMNDiagram id="BPMNDiagram_1">
    <bpmndi:BPMNPlane id="BPMNPlane_1" bpmnElement="Collaboration_1">
      <bpmndi:BPMNShape id="pool_enr_di" bpmnElement="pool_enr" isHorizontal="true">
        <dc:Bounds x="20" y="20" width="1270" height="630" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lane_enr_adm_di" bpmnElement="lane_enr_adm" isHorizontal="true">
        <dc:Bounds x="50" y="20" width="1240" height="240" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lane_enr_fin_di" bpmnElement="lane_enr_fin" isHorizontal="true">
        <dc:Bounds x="50" y="260" width="1240" height="130" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lane_enr_reg_di" bpmnElement="lane_enr_reg" isHorizontal="true">
        <dc:Bounds x="50" y="390" width="1240" height="130" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lane_enr_it_di" bpmnElement="lane_enr_it" isHorizontal="true">
        <dc:Bounds x="50" y="520" width="1240" height="130" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="start_enr_di" bpmnElement="start_enr">
        <dc:Bounds x="112" y="59" width="36" height="36" />
        <bpmndi:BPMNLabel><dc:Bounds x="93" y="101" width="75" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="t_enr_verify_di" bpmnElement="t_enr_verify">
        <dc:Bounds x="230" y="37" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="g_enr_met_di" bpmnElement="g_enr_met">
        <dc:Bounds x="405" y="52" width="50" height="50" />
        <bpmndi:BPMNLabel><dc:Bounds x="389" y="32" width="82" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="t_enr_evidence_di" bpmnElement="t_enr_evidence">
        <dc:Bounds x="530" y="147" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="ev_enr_docs_di" bpmnElement="ev_enr_docs">
        <dc:Bounds x="712" y="169" width="36" height="36" />
        <bpmndi:BPMNLabel><dc:Bounds x="684" y="211" width="92" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="g_enr_split_di" bpmnElement="g_enr_split">
        <dc:Bounds x="555" y="52" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="t_enr_fees_di" bpmnElement="t_enr_fees">
        <dc:Bounds x="680" y="277" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="t_enr_record_di" bpmnElement="t_enr_record">
        <dc:Bounds x="680" y="407" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="g_enr_join_di" bpmnElement="g_enr_join">
        <dc:Bounds x="855" y="422" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="t_enr_it_di" bpmnElement="t_enr_it">
        <dc:Bounds x="980" y="537" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="end_enr_done_di" bpmnElement="end_enr_done">
        <dc:Bounds x="1162" y="559" width="36" height="36" />
        <bpmndi:BPMNLabel><dc:Bounds x="1139" y="601" width="83" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="fenr1_di" bpmnElement="fenr1">
        <di:waypoint x="148" y="77" />
        <di:waypoint x="230" y="77" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr2_di" bpmnElement="fenr2">
        <di:waypoint x="330" y="77" />
        <di:waypoint x="405" y="77" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr3_di" bpmnElement="fenr3">
        <di:waypoint x="455" y="77" />
        <di:waypoint x="555" y="77" />
        <bpmndi:BPMNLabel><dc:Bounds x="461" y="57" width="21" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr4_di" bpmnElement="fenr4">
        <di:waypoint x="455" y="77" />
        <di:waypoint x="510" y="77" />
        <di:waypoint x="510" y="187" />
        <di:waypoint x="530" y="187" />
        <bpmndi:BPMNLabel><dc:Bounds x="461" y="83" width="17" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr5_di" bpmnElement="fenr5">
        <di:waypoint x="630" y="187" />
        <di:waypoint x="712" y="187" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr6_di" bpmnElement="fenr6">
        <di:waypoint x="748" y="187" />
        <di:waypoint x="810" y="187" />
        <di:waypoint x="810" y="242" />
        <di:waypoint x="210" y="242" />
        <di:waypoint x="210" y="77" />
        <di:waypoint x="230" y="77" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr7_di" bpmnElement="fenr7">
        <di:waypoint x="605" y="77" />
        <di:waypoint x="660" y="77" />
        <di:waypoint x="660" y="317" />
        <di:waypoint x="680" y="317" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr8_di" bpmnElement="fenr8">
        <di:waypoint x="605" y="77" />
        <di:waypoint x="660" y="77" />
        <di:waypoint x="660" y="447" />
        <di:waypoint x="680" y="447" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr9_di" bpmnElement="fenr9">
        <di:waypoint x="780" y="317" />
        <di:waypoint x="810" y="317" />
        <di:waypoint x="810" y="447" />
        <di:waypoint x="855" y="447" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr10_di" bpmnElement="fenr10">
        <di:waypoint x="780" y="447" />
        <di:waypoint x="855" y="447" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr11_di" bpmnElement="fenr11">
        <di:waypoint x="905" y="447" />
        <di:waypoint x="960" y="447" />
        <di:waypoint x="960" y="577" />
        <di:waypoint x="980" y="577" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="fenr12_di" bpmnElement="fenr12">
        <di:waypoint x="1080" y="577" />
        <di:waypoint x="1162" y="577" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn2:definitions>

Frequently asked questions

Why does IT provisioning sit after the parallel join instead of inside it?

Account provisioning needs the student record to exist, so it depends on one of the parallel branches. Placing it after the join is the honest ordering: the join guarantees both the record and the fee plan are done. Putting it in a third parallel branch would claim an independence that is not really there and would break in execution.

Could the applicant be modelled as a second pool?

Yes, and it would be defensible: the applicant is an external participant who sends evidence. You would add a black box pool and a message flow into the "Evidence received" event. This example keeps one pool to stay focused on the internal handoffs, which is a reasonable simplification when the external party only ever answers requests.

What would enrolment deadlines look like in this diagram?

The natural spot is the evidence loop: a timer boundary event on the wait, set to the enrolment cut off date, with its own flow to a "Place withdrawn" end event. That converts the open ended loop into one with a hard exit, and it documents the policy that evidence arriving after the deadline no longer rescues the place.

Related BPMN examples

Loan approval

A bank loan approval process as a BPMN 2.0 diagram: completeness check, credit scoring, offer, and payout, with a document rework loop. Download the .bpmn file free.

Mortgage application

A mortgage application mapped in BPMN 2.0: parallel valuation and underwriting, lending decision, offer, and completion. View the swimlanes and download the .bpmn free.

Insurance claim processing

An end to end insurance claim process in BPMN 2.0: registration, cover check, loss assessment, and settlement or decline. Free .bpmn download included.

Patient admission

A hospital patient admission flow as a BPMN 2.0 swimlane diagram: registration, triage, bed request, and ward transfer. Download the .bpmn file free.

Generate your own version of this diagram

Describe how the process works in your organisation: plain English, meeting notes, a transcript, or a spreadsheet. Swimdraft turns it into a spec-validated BPMN 2.0 diagram you can edit in the browser and export as .bpmn, SVG, or PNG.

Start free

No credit card required