Event-driven Process Chain (EPC)

Goal

The event-driven process chain models a process as a sequence of states and steps. Each step sits between the state that triggers it and the state it produces, and the model reads as sentences: "The invoice is received. The benefits department checks the invoice. The invoice is covered, or it is not." A flowchart shows the order of the steps. The EPC also shows the condition that allows each of them.

It answers one question: should a step run and under which combination of conditions? The connectors give the combination: all conditions (AND), at least one (OR), exactly one (XOR, exclusive or). ABPMP's BPM CBOK ranks the EPC among the most powerful notations for identifying the constraints of a process.

The deliverable is a diagram. Hexagons for the events and rounded rectangles for the functions alternate along arrows, with a connector circle at every split and every join. Organisational units, information objects and application systems attach to the side of the functions: the model becomes an extended EPC (eEPC).

The EPC belongs to the process modelling family, alongside the flowchart, BPMN, the UML activity diagram and IDEF. The strict alternation of event and function sets it apart: every step waits for a named state, and an event never decides.

Usage

When to use it

• Processes with many interfaces and sub-models: every link between two chains passes through a named event.
• Detail below the level of an enterprise architecture framework: the EPC goes down to the step and its start condition.
• A start that depends on several conditions: the connector says whether all, at least one or only one must hold.
• Searching for the constraints of a process: every function waits for a named state, and the wait becomes visible.
• Workshops with business experts unused to models: the chain reads back as a sequence of sentences.
• An organisation that already models in ARIS: the repository links each function to its unit, its data and its system.
• A multinational group or German-speaking partners: the CBOK notes that the EPC is widespread in Germany and Europe, especially in multinational enterprises.

When not to use it

• No ARIS licence and no plan to acquire one: generic tooling for the EPC remains thin, so use BPMN.
• A mandate for a Swiss public administration: eCH-0140 adopts BPMN there and eCH-0158 sets its conventions, so use BPMN.
• A short linear process with no combined conditions: the events double the size of the drawing and add nothing, so use the flowchart.

Description

Three objects and their names

An event is the occurrence of a business state of an information object. That state drives the rest of the process. An event happens at a point in time and takes no time. It is drawn as a hexagon. Its label names the object and its change of state: "Invoice received", "Offer rejected". An event triggers functions and results from functions.

A function is a step that takes time. It is drawn as a rectangle with rounded corners and named by a verb and its object: "Check invoice".

A connector is a circle marked AND, XOR or OR. It says how several arrows combine, and the CBOK calls it a rule. A connector with one incoming and several outgoing arrows is a split. A connector with several incoming arrows and one outgoing arrow is a join.

Nüttgens and Rump formalised the syntax of the chain. An event connects only to functions, and a function only to events, directly or through connectors. A function has exactly one incoming and one outgoing arrow, so every split passes through a connector. A chain starts with at least one start event and ends with at least one end event.

The connectors and the event that does not decide

According to the ARIS Methodenhandbuch, the meaning of a connector depends on its position.

An event decides nothing: only a function decides. Linking a triggering event to several functions through an OR or an XOR is therefore illegal. To start several functions, an event passes through an AND, which starts them all in parallel. The rule forces the team to name who decides: the decision function carries the organisational unit that performs it.

A modeller who comes from flowcharts draws this split out of habit: "Invoice received", then an XOR to "Reimburse invoice" or "Reject invoice". The diamond of a flowchart carries a test. An XOR split placed after an event carries none, because nobody has examined the invoice yet. To correct it, the modeller inserts the function that decides, "Check invoice", and places the XOR on its output, leading to two events: "Invoice covered" and "Invoice not covered". Each outcome becomes a named state that the rest of the chain waits for.

The objects attached to a function

Objects attach to the side of a function and describe it: the organisational unit that performs it, the information objects it reads or writes, the application system that supports it. These links do not carry the control flow. ARIS places the EPC in its control view (Steuerungssicht), the view that links its function, organisation and data views. The CBOK adds swimlanes, horizontal or vertical.

The modeller breaks up a long chain. A function refers to a lower-level chain, and a process interface (Prozesswegweiser) marks the point where the chain passes to an upstream or downstream process. The two chains share the event where one ends and the other begins.

Building an EPC

1. Bound the chain by its events. Name the start event and the end events. A team that cannot name the final state has not settled its scope.
2. Lay out the functions in order. One verb and one object per function. Between two functions, write the event that the first produces and the second waits for.
3. Put each decision in a function. Where a function can end in several ways, a connector takes its output: an XOR if the outcomes exclude each other; an OR if several can occur together; an AND if all occur. Each outcome gets its own event.
4. Combine the triggers. Where a function waits for several states, a join placed in front of it states the combination.
5. Merge the branches. Where branches meet, merge them with a join of the same type as the split that opened them. An OR join waits for the branches that the upstream split opened. It learns which ones only by tracing the chain back: Nüttgens and Rump show that its semantics cannot be read locally. When a join has the type of the split that opened its branches, a reviewer can check the two connectors together. A branch that finishes on its own end event has no join; a loop places its XOR join before its XOR split.
6. Look for the event that decides. Check every OR or XOR split placed directly after an event and insert the deciding function in front of it.
7. Attach the objects. Place the unit, the information objects and the system on the functions they concern.
8. Read the chain aloud with the business. A correct EPC reads as a sequence of sentences, which the business experts validate without learning the symbols.

The pitfalls

The trivial event. Writing "Check completed" after every function respects the alternation and says nothing. The event names a state of the object, "Invoice covered", that the rest of the chain waits for. Two functions separated by an empty event often describe a single step.

The unreachable event and the deadlock. The CBOK warns that a team without notation discipline leaves logical gaps. A chain that looks complete hides an event that no path reaches or an AND join placed downstream of an XOR split. That AND waits for a branch that the XOR has ruled out, and the process deadlocks. Closing each split with a join of its own type prevents this deadlock.

Length. Every function brings at least one event. A thirty-step process produces a chain of some sixty nodes, connectors excluded: nearly twice as many as the flowchart of the same process. Levels and process interfaces break up that length.

Tool dependency. According to the CBOK, the most complete implementation of the EPC remains in the ARIS family. Outside ARIS, the model is harder to exchange and maintain than a BPMN model. Some tools translate an EPC into BPMN, and the analyst reviews the result before use.

The Vorgangskettendiagramm, a column layout

The ARIS Vorgangskettendiagramm (VKD) arranges the objects of an extended EPC in columns, one per type: events, functions, organisational units, data, systems. It carries the same content. The columns show at a glance every change of unit, system or data medium from one step to the next, which the free placement of an EPC scatters. The ARIS Methodenhandbuch states the cost: the sequential arrangement of the functions makes branches and processing loops very hard to read. The VKD therefore suits a mostly linear process. ARIS documents the column EPC (Spaltendarstellung) separately, as a different model type.

AI considerations

A language model quickly derives a first chain from a written procedure or an interview record. It proposes the functions, words the events between them and places the connectors. On an exported model, it checks the syntax: an OR or XOR split after an event, a function with two outgoing arrows, two events in a row, an AND join downstream of an XOR. It also drafts the translation of an EPC into BPMN.

It does not know who decides. The source text says "if the invoice is covered" without naming who checks it, and the language model then places an XOR split after the event: the error the notation forbids. The analyst works out with the business which function and which unit decide. The language model also invents trivial events to keep up the alternation. Assigning functions to units sets responsibilities. The analyst validates the assignment with the people concerned. An interview record or a health insurer's procedure often cites real cases: health data, which the Federal Act on Data Protection treats as sensitive personal data. They do not go into a public tool.

Examples

An extended EPC at a health insurer: the reimbursement of a physiotherapy invoice under tiers garant, where the insured person pays and is then reimbursed. The concept the drawing makes visible: where branches meet, the join takes the type of the split.

The XOR on the output of "Check invoice" opens two exclusive branches, and the final XOR join closes them: "Invoice processed" occurs when only one of the two functions, payment or rejection, has finished. The AND that follows "Invoice covered" starts two functions in parallel, and the AND join waits for both results before the payment. An AND join in place of the final XOR would wait for a rejection that never comes for a covered invoice.

Visualisations

Each shape indicates the category of the object: a hexagon for a state, a rounded rectangle for a step, a circle for a combination rule. The drawing reads from top to bottom, and the connectors differ by the mark inside their circle.

The ARIS Methodenhandbuch draws each attached object as a rectangle, marked on the left with the icon of its type: a group of people for the organisational unit, a window for the application system. A line links the unit to the function. An arrow links the information object and shows whether it enters the function, leaves it or both. We place each object type on the same side of every function: the reader finds the unit in the same place at every step.

Cost

Tooling

A whiteboard and sticky notes in two shapes are enough for the first chain in a workshop. General-purpose drawing tools such as Visio or diagrams.net carry EPC shape libraries and suit a standalone model. They do not check the syntax. The open-source bflow* Toolbox models the EPC and detects common modelling errors with validation rules that the administrator can adapt.

ARIS, from Software AG, holds the EPC as a model in its repository. A function or a unit exists there once and is reused from one chain to the next. The organisation and data views stay linked to the functions. The tool flags illegal connections. ARIS pays off when the organisation models its processes over the long term.

Sources

• ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.4 Event Process Chain (EPC): the definition, the origin in ARIS, the use cases, the advantages and the limits of the notation.
• Software AG, ARIS Methodenhandbuch, Version 10.0 Service Release 27, October 2024, §3.4.1.2 Ereignissteuerung, ereignisgesteuerte Prozesskette (EPK): the definition of the event, the meaning of the connectors in each position, the ban on OR and XOR after a triggering event and the mention of the Vorgangskettendiagramm; in §3.1.2 and §3.4.1.3, the symbols of the attached objects and the direction of the arrows to information objects.
• Markus Nüttgens, Frank J. Rump, Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK), Promise 2002, CEUR Workshop Proceedings, vol. 65: the origin at the Institut für Wirtschaftsinformatik of Saarland University with SAP, the syntax rules of the chain, the process interface and the semantics of OR joins.
• eCH, eCH-0158 BPMN modelling conventions for public administration, V1.2: the BPMN standard adopted for Swiss public administration (eCH-0140) and its modelling conventions.