SwimdraftPricingSign inStart free

Refund request BPMN example

Refund requests look simple until money starts leaving the business without a clear rule for who said yes. Teams map the process to make the policy visible: which requests qualify, which amounts need a manager, and who actually triggers the payment. The common failure modes are refunds paid twice because support and finance both acted, and refunds stuck for days because nobody knew a manager had to sign off.

The model here is a single pool with three lanes: Customer support, Support manager, and Finance. Three exclusive gateways carry the logic: a policy check, an amount threshold, and a manager decision. Worth noticing is that both refusal routes converge on one "Send refusal notice" task, so the customer communication is defined once rather than duplicated per branch.

Refund request: BPMN 2.0 diagram
Refund request process modelled as a BPMN 2.0 diagram

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

The process at a glance

Starts when
Refund requested
Ends with
Refund refused · Refund paid
Lanes
Customer support · Support manager · Finance
Decisions
Policy criteria met? · Amount above threshold? · Approval granted?

How to read this diagram

On receipt of a refund request, the Customer support lane reviews it against the returns and refunds policy. The gateway "Policy criteria met?" sends non-qualifying requests down the default No branch to the refusal notice, ending at "Refund refused". Qualifying requests reach a second gateway, "Amount above threshold?", which separates small refunds from those needing sign off.

Small amounts take the default No branch straight to Finance, where the refund payment is processed. Larger amounts route into the Support manager lane for approval, and the gateway "Approval granted?" either releases them to the same payment task or, on the default No branch, joins the refusal path. After payment, support confirms the refund to the customer and the process ends at "Refund paid". Two end states, refused and paid, cover every request.

BPMN elements used

ElementCountIn this diagram
Start event1Refund requested
End event2Refund refused, Refund paid
User task2Review refund request, Approve refund request
Service task1Process refund payment
Send task2Send refusal notice, Confirm refund to customer
Exclusive gateway3Policy criteria met?, Amount above threshold?, Approval granted?
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_rr" name="Refund handling" processRef="Process_pool_rr" />
  </bpmn2:collaboration>
  <bpmn2:process id="Process_pool_rr" isExecutable="false">
    <bpmn2:laneSet id="LaneSet_pool_rr">
      <bpmn2:lane id="lane_rr_sup" name="Customer support">
        <bpmn2:flowNodeRef>start_rr</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>t_rr_review</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>g_rr_policy</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>t_rr_refuse</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>end_rr_refused</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>g_rr_amount</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>t_rr_confirm</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>end_rr_paid</bpmn2:flowNodeRef>
      </bpmn2:lane>
      <bpmn2:lane id="lane_rr_mgr" name="Support manager">
        <bpmn2:flowNodeRef>t_rr_approve</bpmn2:flowNodeRef>
        <bpmn2:flowNodeRef>g_rr_granted</bpmn2:flowNodeRef>
      </bpmn2:lane>
      <bpmn2:lane id="lane_rr_fin" name="Finance">
        <bpmn2:flowNodeRef>t_rr_pay</bpmn2:flowNodeRef>
      </bpmn2:lane>
    </bpmn2:laneSet>
    <bpmn2:startEvent id="start_rr" name="Refund requested">
      <bpmn2:outgoing>f_rr1</bpmn2:outgoing>
    </bpmn2:startEvent>
    <bpmn2:userTask id="t_rr_review" name="Review refund request">
      <bpmn2:incoming>f_rr1</bpmn2:incoming>
      <bpmn2:outgoing>f_rr2</bpmn2:outgoing>
    </bpmn2:userTask>
    <bpmn2:exclusiveGateway id="g_rr_policy" name="Policy criteria met?" default="f_rr4">
      <bpmn2:incoming>f_rr2</bpmn2:incoming>
      <bpmn2:outgoing>f_rr3</bpmn2:outgoing>
      <bpmn2:outgoing>f_rr4</bpmn2:outgoing>
    </bpmn2:exclusiveGateway>
    <bpmn2:sendTask id="t_rr_refuse" name="Send refusal notice">
      <bpmn2:incoming>f_rr4</bpmn2:incoming>
      <bpmn2:incoming>f_rr10</bpmn2:incoming>
      <bpmn2:outgoing>f_rr5</bpmn2:outgoing>
    </bpmn2:sendTask>
    <bpmn2:endEvent id="end_rr_refused" name="Refund refused">
      <bpmn2:incoming>f_rr5</bpmn2:incoming>
    </bpmn2:endEvent>
    <bpmn2:exclusiveGateway id="g_rr_amount" name="Amount above threshold?" default="f_rr7">
      <bpmn2:incoming>f_rr3</bpmn2:incoming>
      <bpmn2:outgoing>f_rr6</bpmn2:outgoing>
      <bpmn2:outgoing>f_rr7</bpmn2:outgoing>
    </bpmn2:exclusiveGateway>
    <bpmn2:userTask id="t_rr_approve" name="Approve refund request">
      <bpmn2:incoming>f_rr6</bpmn2:incoming>
      <bpmn2:outgoing>f_rr8</bpmn2:outgoing>
    </bpmn2:userTask>
    <bpmn2:exclusiveGateway id="g_rr_granted" name="Approval granted?" default="f_rr10">
      <bpmn2:incoming>f_rr8</bpmn2:incoming>
      <bpmn2:outgoing>f_rr9</bpmn2:outgoing>
      <bpmn2:outgoing>f_rr10</bpmn2:outgoing>
    </bpmn2:exclusiveGateway>
    <bpmn2:serviceTask id="t_rr_pay" name="Process refund payment">
      <bpmn2:incoming>f_rr7</bpmn2:incoming>
      <bpmn2:incoming>f_rr9</bpmn2:incoming>
      <bpmn2:outgoing>f_rr11</bpmn2:outgoing>
    </bpmn2:serviceTask>
    <bpmn2:sendTask id="t_rr_confirm" name="Confirm refund to customer">
      <bpmn2:incoming>f_rr11</bpmn2:incoming>
      <bpmn2:outgoing>f_rr12</bpmn2:outgoing>
    </bpmn2:sendTask>
    <bpmn2:endEvent id="end_rr_paid" name="Refund paid">
      <bpmn2:incoming>f_rr12</bpmn2:incoming>
    </bpmn2:endEvent>
    <bpmn2:sequenceFlow id="f_rr1" sourceRef="start_rr" targetRef="t_rr_review" />
    <bpmn2:sequenceFlow id="f_rr2" sourceRef="t_rr_review" targetRef="g_rr_policy" />
    <bpmn2:sequenceFlow id="f_rr3" name="Yes" sourceRef="g_rr_policy" targetRef="g_rr_amount">
      <bpmn2:conditionExpression xsi:type="bpmn2:tFormalExpression">Yes</bpmn2:conditionExpression>
    </bpmn2:sequenceFlow>
    <bpmn2:sequenceFlow id="f_rr4" name="No" sourceRef="g_rr_policy" targetRef="t_rr_refuse" />
    <bpmn2:sequenceFlow id="f_rr5" sourceRef="t_rr_refuse" targetRef="end_rr_refused" />
    <bpmn2:sequenceFlow id="f_rr6" name="Yes" sourceRef="g_rr_amount" targetRef="t_rr_approve">
      <bpmn2:conditionExpression xsi:type="bpmn2:tFormalExpression">Yes</bpmn2:conditionExpression>
    </bpmn2:sequenceFlow>
    <bpmn2:sequenceFlow id="f_rr7" name="No" sourceRef="g_rr_amount" targetRef="t_rr_pay" />
    <bpmn2:sequenceFlow id="f_rr8" sourceRef="t_rr_approve" targetRef="g_rr_granted" />
    <bpmn2:sequenceFlow id="f_rr9" name="Yes" sourceRef="g_rr_granted" targetRef="t_rr_pay">
      <bpmn2:conditionExpression xsi:type="bpmn2:tFormalExpression">Yes</bpmn2:conditionExpression>
    </bpmn2:sequenceFlow>
    <bpmn2:sequenceFlow id="f_rr10" name="No" sourceRef="g_rr_granted" targetRef="t_rr_refuse" />
    <bpmn2:sequenceFlow id="f_rr11" sourceRef="t_rr_pay" targetRef="t_rr_confirm" />
    <bpmn2:sequenceFlow id="f_rr12" sourceRef="t_rr_confirm" targetRef="end_rr_paid" />
  </bpmn2:process>
  <bpmndi:BPMNDiagram id="BPMNDiagram_1">
    <bpmndi:BPMNPlane id="BPMNPlane_1" bpmnElement="Collaboration_1">
      <bpmndi:BPMNShape id="pool_rr_di" bpmnElement="pool_rr" isHorizontal="true">
        <dc:Bounds x="20" y="20" width="1420" height="500" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lane_rr_sup_di" bpmnElement="lane_rr_sup" isHorizontal="true">
        <dc:Bounds x="50" y="20" width="1390" height="240" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lane_rr_mgr_di" bpmnElement="lane_rr_mgr" isHorizontal="true">
        <dc:Bounds x="50" y="260" width="1390" height="130" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="lane_rr_fin_di" bpmnElement="lane_rr_fin" isHorizontal="true">
        <dc:Bounds x="50" y="390" width="1390" height="130" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="start_rr_di" bpmnElement="start_rr">
        <dc:Bounds x="112" y="59" width="36" height="36" />
        <bpmndi:BPMNLabel><dc:Bounds x="85" y="101" width="90" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="t_rr_review_di" bpmnElement="t_rr_review">
        <dc:Bounds x="230" y="37" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="g_rr_policy_di" bpmnElement="g_rr_policy">
        <dc:Bounds x="405" y="52" width="50" height="50" />
        <bpmndi:BPMNLabel><dc:Bounds x="383" y="32" width="95" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="t_rr_refuse_di" bpmnElement="t_rr_refuse">
        <dc:Bounds x="980" y="37" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="end_rr_refused_di" bpmnElement="end_rr_refused">
        <dc:Bounds x="1162" y="169" width="36" height="36" />
        <bpmndi:BPMNLabel><dc:Bounds x="1141" y="211" width="78" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="g_rr_amount_di" bpmnElement="g_rr_amount">
        <dc:Bounds x="555" y="52" width="50" height="50" />
        <bpmndi:BPMNLabel><dc:Bounds x="516" y="32" width="128" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="t_rr_approve_di" bpmnElement="t_rr_approve">
        <dc:Bounds x="680" y="277" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="g_rr_granted_di" bpmnElement="g_rr_granted">
        <dc:Bounds x="855" y="292" width="50" height="50" />
        <bpmndi:BPMNLabel><dc:Bounds x="834" y="272" width="92" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="t_rr_pay_di" bpmnElement="t_rr_pay">
        <dc:Bounds x="980" y="407" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="t_rr_confirm_di" bpmnElement="t_rr_confirm">
        <dc:Bounds x="1130" y="37" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="end_rr_paid_di" bpmnElement="end_rr_paid">
        <dc:Bounds x="1312" y="59" width="36" height="36" />
        <bpmndi:BPMNLabel><dc:Bounds x="1299" y="101" width="62" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="f_rr1_di" bpmnElement="f_rr1">
        <di:waypoint x="148" y="77" />
        <di:waypoint x="230" y="77" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="f_rr2_di" bpmnElement="f_rr2">
        <di:waypoint x="330" y="77" />
        <di:waypoint x="405" y="77" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="f_rr3_di" bpmnElement="f_rr3">
        <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="f_rr4_di" bpmnElement="f_rr4">
        <di:waypoint x="455" y="77" />
        <di:waypoint x="510" y="77" />
        <di:waypoint x="510" y="132" />
        <di:waypoint x="960" y="132" />
        <di:waypoint x="960" y="77" />
        <di:waypoint x="980" y="77" />
        <bpmndi:BPMNLabel><dc:Bounds x="461" y="83" width="17" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="f_rr5_di" bpmnElement="f_rr5">
        <di:waypoint x="1080" y="77" />
        <di:waypoint x="1110" y="77" />
        <di:waypoint x="1110" y="187" />
        <di:waypoint x="1162" y="187" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="f_rr6_di" bpmnElement="f_rr6">
        <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:BPMNLabel><dc:Bounds x="611" y="57" width="21" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="f_rr7_di" bpmnElement="f_rr7">
        <di:waypoint x="605" y="77" />
        <di:waypoint x="960" y="77" />
        <di:waypoint x="960" y="447" />
        <di:waypoint x="980" y="447" />
        <bpmndi:BPMNLabel><dc:Bounds x="611" y="83" width="17" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="f_rr8_di" bpmnElement="f_rr8">
        <di:waypoint x="780" y="317" />
        <di:waypoint x="855" y="317" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="f_rr9_di" bpmnElement="f_rr9">
        <di:waypoint x="905" y="317" />
        <di:waypoint x="960" y="317" />
        <di:waypoint x="960" y="447" />
        <di:waypoint x="980" y="447" />
        <bpmndi:BPMNLabel><dc:Bounds x="911" y="297" width="21" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="f_rr10_di" bpmnElement="f_rr10">
        <di:waypoint x="905" y="317" />
        <di:waypoint x="960" y="317" />
        <di:waypoint x="960" y="77" />
        <di:waypoint x="980" y="77" />
        <bpmndi:BPMNLabel><dc:Bounds x="911" y="323" width="17" height="14" /></bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="f_rr11_di" bpmnElement="f_rr11">
        <di:waypoint x="1080" y="447" />
        <di:waypoint x="1110" y="447" />
        <di:waypoint x="1110" y="77" />
        <di:waypoint x="1130" y="77" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="f_rr12_di" bpmnElement="f_rr12">
        <di:waypoint x="1230" y="77" />
        <di:waypoint x="1312" y="77" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn2:definitions>

Frequently asked questions

Why chain two gateways instead of one gateway with three branches?

Because the questions are different. "Policy criteria met?" is about eligibility and "Amount above threshold?" is about authority, and each has its own owner. Collapsing them into one three-way gateway would need compound conditions like "eligible and above threshold", which are harder to read and harder to keep correct when the policy changes.

Why do both refusal branches point at the same send task?

Pointing two sequence flows at one task is a legal and tidy way to merge exclusive paths in BPMN. It guarantees the customer gets the same refusal notice whether the request failed the policy check or the manager declined it. If the two messages needed different content, you would split them into separate tasks.

How would I extend this model for card chargebacks?

Add a branch after "Policy criteria met?" or a separate start event for disputes raised through the card scheme, then give the chargeback path its own evidence gathering task and a deadline. A timer intermediate event works well there, because card schemes impose fixed response windows that the process must not miss.

Related BPMN examples

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