Lifecycle transition

What is a lifecycle transition?

A lifecycle transition is an event that records an activity instance moving from one execution state to another. Common transitions are schedule, assign, start, suspend, resume, complete, and abort, and each one is a timestamped event rather than a lasting state.

Many event logs record only a single complete event per activity. Once a log carries both start and complete, the analysis can separate how long the work was actively in progress from how long it waited. The IEEE XES standard defines a lifecycle extension for these transitions and a model for activity instances, so different tools read them the same way.

Activity, event and instance

The activity "Review application" is a step in the process. One concrete run of it for case 123 is an activity instance. Start and complete are two events of that same instance, each with its own timestamp, and each can carry resource and data attributes.

Without an instance ID, preparation has to pair those events itself. When an activity repeats or runs in parallel, the activity name and order alone can be too little to match a start to the right complete.

A simple example

A task is scheduled at 09:00, started at 10:15, and finished at 10:45. The throughput time from when it was offered is 105 minutes, while the active service time is 30 minutes. A log holding only the 10:45 complete cannot tell those apart, so the analysis may count waiting time as working time. Add assign events and you can also see when a resource picked the task up and how long it sat in their queue.

Pairing start and complete

Use a stable activity instance ID when the source system provides one. Otherwise a correlation rule has to combine case, activity, resource, and order to reconstruct the pairs. With loops the same activity can appear several times in one case, so naively matching the first start to the first complete can be wrong. Keep uncertain or unpaired events and report them, because quietly dropping them makes execution time look artificially clean.

The standard transitions

Suspend and resume mark work being paused and picked up again. Abort and its relatives record different unsuccessful endings when the source distinguishes them reliably. Schedule and assign help you study queue and hand-off time. Not every system means the same thing by each label: a status of "In progress" is not automatically a genuine start, so map source statuses onto a controlled lifecycle vocabulary and write down the assumptions you made.

Lifecycle transition versus status

A transition is an event: at a moment, a change happens. A status is the condition that holds between two transitions. A database that stores only the current status has no full history, so audit or change tables are needed to rebuild the transitions. Do not manufacture events from a snapshot as if the real transition times were known.

What to watch out for with lifecycle transitions

Look for a complete with no start, negative durations, impossibly long instances, and overlapping runs the process should not allow. Clocks on different systems drift, so check time zones and synchronisation before you calculate any duration. Watch how the source logs the events, too: an application that writes start when a form opens and complete when it saves measures screen-open time, not pure working time, if the user does other things in between. For control-flow discovery a single lifecycle such as complete is often used to avoid double labels, while performance analysis keeps both start and complete to compute service and waiting time. Make it explicit per analysis which transitions you select or merge, or two dashboards on the same source can show different activity counts.