The operational sequence of functions in the sense of business processes is represented in process chains. The start and end events of every function can be specified. Not only do events trigger functions, they also represent results of functions.

An event describes the fact that an information object has taken on a business management-relevant state that controls or influences the progression of the business process. Events trigger functions and are the results of functions. Unlike a function, which is a time-consuming task, an event relates to one point in time.

The change in state of an information object may refer to the first occurrence of this information object (for example, Customer order received), or to a change in state in the sense of a change in status recorded in an attribute occurrence (for example, Offer is refused). Since information objects and attributes are described in the ARIS data view, the event-driven representation of process chains forms a link between the data view and the function view and is thus attributed to the ARIS control view.

Events are graphically represented as hexagons. The name should not only contain the information object itself (Order), but also its state change (received). The following figure illustrates events.

Events trigger functions and are the results of functions. By arranging events and functions in a sequence, so-called Event-driven process chains (EPCs) are created. An event-driven process chain (EPC) shows the chronological-logical operational sequence of a business process.

An example of an EPC is shown in the following figure. Since events determine which state or condition will trigger a function and which state will define the end of a function, the start and end nodes of such an EPC are always events. Multiple functions can originate from one event simultaneously, and a function can have multiple events as its result. A rule that is represented by a circle is used to illustrate branches and processing loops in an EPC. However, these connections do not only serve as graphic operators, but define the logical links between the objects they connect.

In the first example of this figure the start events are connected via an AND rule. This means that the Release operation procedure is started only if the routing and the required resources are available. Therefore, both events must have occurred before the procedure can begin. The second example shows an exclusive OR connection using an XOR rule. The Check supplier offer function may result in either acceptance or rejection of the quote. Both results, however, cannot occur at the same time. Besides these two cases and links of the 'inclusive OR' type, more complex relationships are possible.

Thus, two different types of operators exist:

An overview of all possible event and function operators is listed in the following figure (see Hoffmann, Kirsch, Scheer, 'Modellierung mit Ereignisgesteuerten Prozessketten' [Modeling with event-driven process chains], 1993, p. 13).

In this context, special attention must be paid to the restrictions which exist for function operators. Due to the fact that events cannot make decisions (only functions can do this), a triggering event must not be linked using an OR or XOR operator.

Below, possible operators are explained using examples.

The function can be started only after all events have occurred.

The function is carried out after at least one of the events has occurred.

The function is started after no more than exactly one event has occurred.

All events will occur after function execution is complete.

At least one of the events will occur after function execution is complete.

No more than one event will occur after function execution is complete.

The event occurs only after all functions have been carried out.

The event occurs after at least one of the functions has been carried out.

The event occurs after no more than exactly one function has been carried out.

The event triggers all functions.

Events have no decision-making power. This operator is invalid.

Events have no decision-making power. This operator is invalid.

Besides being illustrated in the form of event-driven process chains, these branches can also be represented in table form in the event and function columns of a process chain diagram (see chapter Process chain analysis). Since functions are sorted sequentially in a process chain diagram, branches and processing loops can be represented only in a rather complex and thus confusing manner.