Directly-Follows Graph (DFG)

What is a Directly-Follows Graph?

A Directly-Follows Graph, or DFG, is the most basic way to picture a process from data. Each box is an activity, and an arrow from A to B means that at some point B happened right after A. That is the whole idea.

It is the first thing almost every process mining tool shows you, from Celonis to Fluxicon's Disco, because it is cheap to compute and instantly readable. If you have ever seen a process laid out as boxes and arrows with numbers on them, you have almost certainly seen a DFG.

From an event log to a DFG

Take two cases: A, B, C and A, D, C. The DFG draws four arrows: A to B, B to C, A to D, and D to C. Every time two activities sit next to each other in a case, the matching arrow is drawn or its count goes up.

If A, B, C happens a hundred times and A, D, C happens five times, the arrows on the busy path carry a higher number. What the graph does not remember is which full case produced which arrow. It keeps the local steps and throws away the end-to-end story.

Frequency and performance views

Most tools offer two readings of the same graph. A frequency view shows how often each activity and each step occurs, so the dominant routes stand out through thicker or labelled arrows. When you show a percentage, always say what it is a percentage of: cases or transitions.

A performance view puts time on the arrows instead, such as the median time between one activity finishing and the next one starting. Be careful reading this as waiting time, and lean on medians and percentiles rather than averages, since one extreme case can badly distort a rare arrow.

Where a Directly-Follows Graph misleads you

The DFG has one serious blind spot: it cannot tell the difference between activities that run in parallel and activities that are a genuine choice. If A and B appear in both orders, that might mean they run at the same time, or it might just be two different kinds of case laid on top of each other.

It also has no execution semantics. When several arrows point into one activity, the graph never says whether that activity waits for all of them or just one. For that kind of question you need a model that actually defines behaviour, such as a Petri net or a process tree.

DFG versus a process variant

A process variant is a full end-to-end path: all the cases that went through exactly the same sequence of activities. A DFG merges the local steps from every case into one picture.

The side effect is that a DFG can suggest a route that no single case ever actually took, because it stitches together arrows from different cases. When you need to know what really happened from start to finish, use variant analysis, not the graph.

DFG versus a full process model

A DFG is descriptive and easy to produce, but it does not formally define what is allowed to happen. A Petri net or a process tree does, which is what lets you replay cases against it and run conformance checking.

None of this makes the DFG useless. It is an excellent starting point for exploring a log, filtering it down, and deciding which discovery algorithm to run next. It just should not be the final word.

What to watch out for with a Directly-Follows Graph

Real logs look like spaghetti. A raw DFG from live data is usually a dense tangle of rare arrows. Filter on activity or arrow frequency to see the main flow, but remember that filtering changes the story, so keep the counts.

Rare paths are not automatically noise. Compliance breaches and expensive exceptions are often the rare arrows. Do not delete them on sight.

Bad data invents arrows. Wrong case linking, duplicate events, or a tie in timestamps can all create steps that never happened. Trace a surprising arrow back to real cases before you trust it.

Write down your choices. Activity mapping, the time metric, and the correlation rules all shape the graph. Without them, nobody can reproduce it.