Key Components of EPC Diagrams: Events, Functions, and Connectors

Estimated reading: 8 minutes 7 views

Never model a process without first asking: “What triggers this?” This simple rule prevents 90% of structural failures in EPC diagrams. Misidentifying a trigger as a function or failing to link events properly creates logical gaps that propagate through workflows, leading to confusion in audits, automation design, and stakeholder alignment. I’ve seen teams spend weeks fixing broken flows that originated from a single mislabeled event. This chapter breaks down the three foundational EPC diagram elements—events, functions, and connectors—with real-world examples, pattern recognition, and common pitfalls to avoid.

By the end of this section, you’ll know how to distinguish between a true event and a mere task, how to apply EPC connectors to model decision logic, and how to structure your models for maximum clarity and maintainability. You’ll also learn how EPC components explained in practice reflect real business behavior—not just abstract notation.

Events: The Starting and Ending Points of Business Logic

Events are the heartbeat of any EPC diagram. They represent a state change in the business—something that happens, not something that’s done.

Think of an event as a signal: “The customer has paid.” Not “We received the payment,” but the moment the payment is confirmed. That distinction is crucial.

Events are always written in rounded rectangles and must be **observable and measurable**. A valid event must answer: “What changed?”

Types of Events

Start Event: The initial trigger that begins a process. It represents the first known state change, such as “Order Received” or “Payment Confirmed.”
End Event: The final state that completes the process. It signifies the business outcome, such as “Invoice Sent” or “Product Delivered.”
Intermediate Event: A state change that occurs between the start and end. These are often conditions that must be met before a function can proceed, like “Credit Check Passed” or “Approval Received.”

Many beginners confuse functions with events. A function is an action, while an event is a result. For example, “Process Payment” is a function. “Payment Processed” is an event.

Best Practices for EPC Events

Here’s how to write strong event statements:

Use present or past tense, but be consistent. “Invoice Generated” is clearer than “Generate Invoice.”
Focus on outcome, not action. “Order Approved” is better than “Manager Approves Order.”
Ensure events are independent of any control flow. An event should be valid whether or not the process is running.

When I review EPC diagrams, I always flag events that read like verbs. They’re usually functions in disguise.

Functions: The Actions That Drive the Process

Functions represent the actual tasks or actions that must be performed to move from one event state to another.

They are written in rectangles, and the verb is typically the first word: “Verify Customer Data,” “Approve Order,” “Ship Product.”

Functions are not decisions. They are activities that consume time and resources. They are the “work” in business processes.

Key Characteristics of EPC Functions

Do not start with “When” or “If.” These are event qualifiers.
Be specific and unambiguous. Avoid vague statements like “Handle Payment.” Instead, use “Process Credit Card Payment” or “Initiate Refund.”
Assign ownership. While EPC doesn’t require it, adding an organizational unit (e.g., “Finance Team”) improves traceability.

Consider this: if a function can’t be assigned to a responsible person or system, it may be too abstract.

Common Pitfalls in Function Modeling

Using “Update Database” as a function — this is an IT detail, not a business action. Replace with “Update Order Status in CRM.”
Grouping multiple actions into one function — e.g., “Process Order” — when it should be split into “Validate Order,” “Check Stock,” “Book Shipment.”
Repeating the same event as a function — e.g., “Customer Confirmed Order” and “Order Confirmed” — leads to redundancy.

When I model a customer onboarding process, I break every function down to its smallest meaningful action. It may seem excessive at first, but this precision prevents misunderstandings later.

Connectors: The Logic That Shapes the Flow

Connectors, or logical operators, define how events and functions are linked and how branching occurs.

They are the glue that holds EPC logic together. Without them, the flow becomes ambiguous or incorrect.

Types of EPC Connectors

There are three primary logical connectors in EPC:

Connector	Symbol	Meaning	Example
AND	Parallel lines	All incoming events must occur before the next function or event	“Payment Received” AND “Order Valid” → “Process Shipment”
OR	Split with a circle	One or more incoming events trigger the next step	“Payment Failed” OR “Order Cancelled” → “Notify Customer”
XOR	Circle with a cross	Exactly one of the incoming events must occur	“Credit Check Passed” XOR “Credit Check Failed” → “Approval Decision”

When to Use Each Connector

AND: Use when all conditions must be met. For example, a shipment can only be dispatched if both inventory is available and the invoice is paid.
OR: Use when any one condition leads to the next step. For example, if a customer service issue is reported via email or phone, the ticket is created.
XOR: Use when exactly one condition applies. Avoid XOR if more than one can be true, as it can break logic.

Pro tip: Use XOR only when you’re certain only one event can occur. Otherwise, OR is safer and more flexible.

One of the most common mistakes I see is using AND when OR is intended. For example, “Credit Check Passed” AND “Fraud Check Passed” — but if either fails, the customer should be flagged. That’s an OR situation for decision-making.

How EPC Events and Functions Interact

Every function must follow an event and precede another event. The flow is always: Event → Function → Event → Function → Event.

This sequence ensures that every action is triggered by a state change and leads to a new state.

Consider a returns process:

Event: “Customer Requests Return”
Function: “Inspect Returned Item”
Event: “Return Approved” OR “Return Denied”
Function: “Issue Refund” (if approved)
Event: “Refund Processed”

Notice how the function “Issue Refund” appears only if “Return Approved” occurs. This is where EPC connectors come in.

Modeling Decision Points with EPC Connectors

When multiple outcomes are possible, use XOR or OR connectors to model the branching logic.

For example:

Event: “Return Received”
Function: “Inspect Item”
Event: “Item Damaged” XOR “Item in Good Condition”
Function: “Process Refund” (if good) OR “Reject Refund” (if damaged)

Here, XOR ensures the next function depends on exactly one outcome. This prevents both actions from occurring, which would be a logic error.

Organizational Units and EPC Components Explained

While not part of the core logic, organizational units help clarify responsibility and improve traceability.

They are typically placed beneath functions in the diagram, like: “Finance Team” or “Customer Service Department.”

When modeling EPC, I always ask: “Who owns this task?” If no one can be assigned, the function may be too abstract.

Another useful pattern: group functions by responsible unit. This helps in stakeholder alignment and process ownership.

Practical Example: Order Fulfillment Workflow

Let’s walk through a simple EPC diagram for a retail order process:

Event: “Order Placed”
Function: “Validate Order Details”
Event: “Order Valid”
Function: “Check Inventory”
Event: “Stock Available” AND “Payment Confirmed” → “Process Shipment”
Function: “Ship Order”
Event: “Shipment Sent”

Note: “Stock Available” and “Payment Confirmed” are connected with AND. Both must be true before “Process Shipment” can occur.

This example shows how EPC connectors are not just lines—they represent real business rules.

Common Mistakes to Avoid

Using functions as events: “Send Email” is a function, not an event. “Email Sent” is the correct event.
Overusing XOR: if multiple outcomes are possible, use OR instead.
Skipping intermediate events: this leads to ambiguous flows. Always define the state change after a function.
Confusing the direction of flow: EPC flows from left to right or top to bottom. Always ensure inputs feed into outputs.

Final Checklist: Are Your EPC Diagram Elements Correct?

Each event is a measurable state change.
Every function is an action, not a condition.
Functions are preceded by events and lead to new events.
Connectors are used correctly: AND, OR, XOR based on logic.
Organizational units clarify responsibility where needed.

Frequently Asked Questions

What is the difference between an event and a function in EPC?

An event is a state change, like “Payment Received.” A function is an action, like “Record Payment.” Events trigger functions. Functions produce new events.

Can I use OR and AND together in one EPC connector?

Yes, but not on the same connector node. You can have multiple outgoing paths from a single event using different connectors. For example, one path with AND, another with OR, depending on the business logic.

How do I know when to use XOR instead of OR?

Use XOR when exactly one of several conditions must be true. Use OR when one or more can be true. In most real-world scenarios, OR is safer and more flexible.

What happens if I omit an intermediate event?

Omitting an intermediate event creates ambiguity. The next function may be triggered by multiple causes, leading to incorrect process behavior. Always ensure every function is preceded by a clear state change.

Can EPC connectors be used in loops?

Yes, EPC connectors can be used in iterative processes. For example, “Process Order” → “Check Status” → “Status Completed?” XOR “Status Pending” → “Wait” — allows feedback loops.

Is it bad to use too many EPC connectors?

Not inherently. But ensure each connector reflects real business logic. Overuse often indicates overly granular modeling. Balance clarity with simplicity. If a connector doesn’t serve a meaningful decision, reconsider the structure.