Skip to main content

Performance Spectrum

This feature is currently available as a Private Preview only

During a Private Preview, only customers who have agreed to our Private Preview usage agreements can access this feature. Additionally, the features documented here are subject to change and / or cancellation, so they may not be available to all users in future.

For more information about our Private Preview releases, including the level of Support offered with them, see: Feature release types.

The Performance Spectrum component is a visual tool that brings your process data to life. It displays every process step in sequence along a timeline, showing how individual cases progress over time. The Performance Spectrum is configured by dragging and dropping the component into a Studio View and then selecting the event log from your Knowledge Model.

By adding a time dimension to your process map, the Performance Spectrum helps you:

  • See how multiple cases unfold in parallel

  • Identify bottlenecks, delays, and recurring issues

  • Understand how process variations impact performance

Traditional process explorers show aggregated views that can overlook real process dynamics. The Performance Spectrum adds a time-based perspective, revealing how tasks interact and evolve. It highlights variations, bottlenecks, and performance shifts that are often hidden in static summaries, giving you clearer insights into how your processes truly run.

In this use case example, a local government agency is using the Performance Spectrum to visualize their traffic fine process. The current process steps are:

  1. Create fine after incident.

  2. Send fine to individual.

  3. Insert fine notification.

  4. Add penalty.

  5. Send for credit collection.

They usually see a process graph showing the average time each step takes. For example, they might know that the average time from “Create Fine” to “Payment” is 30 days. However, this average doesn’t reveal when fines get stuck, why some take longer, or whether bottlenecks occur on specific days. They can’t see how individual fines actually flow through the process.

The solution: Using the Performance Spectrum

The Performance Spectrum helps the government agency to define a specific sequence of the steps involved and visualize how individual fines move through that defined sequence over time. This helps them to identify bottlenecks and validate that specific process patterns (like batching) are adhered to.

Performance_spectrum_example.png

The government agency can then analyze the data in the spectrum, coming to the following conclusions:

  • Batching: Multiple 'Send Fine notifications' are grouped and processed together and the batches themselves are not sent at regular intervals.

  • Drift: The drift for 'Insert Fine notifications' shows that a few notifications take much longer to send than the majority.

  • Frequency of events: The 'Adding penalty' event constantly occurs 60 days after the fine notification.

 

The Performance Spectrum is configured by dragging and dropping the component into a Studio View and then selecting one or multiple the event logs from your Knowledge Model. In addition, you can define a default sequence per event log that you would like to use for your analysis (more details below). This sequence can also be changed during analysis time.

Before configuring the component though, we recommend either identifying a set of low-performing cases in your View or reviewing the complete execution history of a specific object instance to diagnose issues.

Once you've identified these cases:

  1. In View Edit mode, drag and drop the Performance Spectrum component onto your canvas.

    drag_and_drop_component.png
  2. In the Settings panel, select the Event Log to display.

    select_event_log.png
  3. In Interactive Mode, select a base variant to get to your final sequence faster. In the following steps you can further modify this variant:

    • Adding or removing events:

      remove_event.gif
    • Defining connection types between events: For start and end event you can also choose whether the start / end event should be the first / last (must start / end here) in the sequence or other events can happen before / after (can be started / ending here).

      • Directly followed: Events must occur immediately one after another.

      • Followed anytime: Other unrelated events can occur between the defined events.

      connection_types.gif
  4. Deploy your application, making it available in the Apps area.

    To learn more about creating versions and deploying your apps, see: Versioning and deploying packages.

  5. Use the published Performance Spectrum to analyze your data.

Here are some commonly seen patterns when using the Performance Spectrum:

Pattern

Visual

Explanation

Batching

Patterns_-_batching.png

Multiple object instances are grouped and processed together.

Constant speed

Pattern_-_constant_speed.png

Object instances progress at a consistent rate over time.

Drift

Pattern_-_drift.png

The rate at which object instances progress changes gradually.

First in first out (FIFO)

Patterns_-_first_in_last_out.png

Object instances are completed in the order they begin.

Last in first out (LIFO)

Pattern_-_last_in.png

The most recent object instances are completed first.

Unordered

Patterns_-_unordered.png

Object instances are completed in a seemingly random order.