In this transformation step, the events for the entities are defined. Each record in an event table represents one event that took place for the EntityEntity - An object of interest for which you want to see how it behaves through the process.. In most situations, more data records are created. This is the result of joins and unions to link the events to each entity they belong to.
Before building the event tables, it is important to understand the main activities in the process. Prioritize adding activities based on how often they will likely occur and how meaningful they are to the end user. Defining the activities should be an iterative process.
Start with the high-value activities. These are the main activities in the process that describe the core of the process. With only the main activities you can already start validating the process.
An ideal number of activities is between 10 and 20. With a small number of activities there will not be a lot of possible variation in the process. More activities increase the number of process variants. With more process variants, you have to reduce the complexity of the process graphs to understand the flow. This also makes it harder to come to general conclusions.
See the table below.
Number of activities
Low analysis complexity, low number of potential improvements.
Optimal balance of analysis complexity and potential improvements.
High analysis complexity, high number of small improvements.
In an event table, each record should represent exactly one event. On a high level, there are two scenarios on how the data is structured:
- One or more tables with multiple timestamp columns.
- One or more tables with one timestamp column (transaction log).
Each scenario requires different transformations.
In this scenario, multiple timestamp properties could be defined on the entity table. Consider the example in which an invoice entity is described with three timestamp columns. Each column stores the timestamps of an activity:
- creation of the invoice,
- deletion of the invoice,
- price change.
See the illustration below.
For each of the columns, a new table that represents the events of that activity is created. Each of the event tables needs an activity definition to indicate which event is performed, a timestamp that indicates when this happened, and the invoice ID to know for which invoice the event is performed. See the illustration below for the resulting tables.
The resulting event table for the invoice entity can be created by a union of the separate event tables.
Make sure to only have records in each table for which an activity name is available and a timestamp is known.
This scenario applies when the input data contains a transaction or audit log containing a record for each event that is happening. A transaction log may contain events corresponding to several entities. Consider the example that the transaction log stores events related to purchases and to invoices. See the illustration below.
In this case, you should create an event table per entity. This increases the number of tables in the connector, but it will keep the structure clear. In the example, the log is split into purchase events and invoice events and the columns are renamed. See the illustration below for the resulting tables.
Event tables are usually the largest table in the connector. Make sure to filter out any unwanted records in the joins. A wrong join condition can easily blow up the data volume you have. Look at the number of records in the event table. Is the number higher or lower than expected, then review the join conditions.
Event end are mandatory attributes in the event tables. These attributes describe for which entity an event occurs, what the event is, and when the event was performed.
A unique key is required to identify the entity for which a certain event happens. In the scenario of multiple entities in your process, you will also have multiple event tables. The entity ID on each of the event tables is important if you want to create the end-to-end event log. The creation of the event log will be discussed in Chapter 5: Event log.
The activity describes which event took place. If the name of the activity is not derived from the values in the data, you need to make an expression to define the name yourself. You can infer the activity name from the column names. For example, you can define the activity
Create document based on the column
document_creation_date. If the column names are less descriptive, you should consult with the process expert for a meaningful name that resonates with the end users.
When naming the activity yourself, best practice is to use the Verb Noun format, such as
Create document. Most activities are transactional and this naming convention conveys that. See the table below for some advice on activity naming.
Avoid ambiguous activity names.
Avoid singular activity names, state what happened to what.
Avoid passive tense.
Approve credit control check on the sales order
Avoid too long activity names
Approve SO credit check
The event end attribute indicates when the specific event was performed. For analysis, the event end is used as the timestamp of the event, because usually in the data the time is available of when the event is finished. The event end should be as detailed as possible. A date is generally not sufficient since multiple events can happen on the same date.
In the event tables you can add additional properties for events. For example, the event detail or supporting properties to define an open or closed case. It is advised to only add the additional attributes after the event logic is validated. Optional attributes may be required for specific visualizations. The attributes
Event cost and
Event processing time (also called ‘work estimates’) are, for example, required for analyzing automation opportunities.
Updated 3 months ago