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:

  • Queueing and bottlenecks: They immediately notice a large build-up of dots (fines) between "Insert Fine Notification" and "Add Penalty" at the end of each month. This indicates a significant backlog forming at the penalty addition step during specific periods.

    They realize there is a major bottleneck for fines waiting to have penalties added, especially around month-end, which wouldn’t have been visible from averages alone.

  • Batching: They observe that many fines jump from "Add Penalty" to "Payment" all at once around the 5th of each month, showing that payments are processed in large batches rather than continuously. They understand that batching explains why some fines wait for days after penalties are added until the next payment run. They also notice that batches are far apart in time, with gaps such as no fines being sent between June and October, highlighting inefficient cash management.

  • LIFO (Last-In, First-Out) for penalties: They might see that a fine created on July 20th receives its penalty before a fine created on July 15th, even though the older fine arrived earlier at the "Add Penalty" step. They realize that newer fines sometimes jump ahead in processing, meaning older fines can accumulate additional delays.

  • Deviations and outliers: They spot individual fines with unusually long waiting times right after "Create Fine." Investigating further, they find these fines require manual address verification before "Send Fine," causing significant individual delays. They see that specific fines get stuck early due to address issues, a deviation that would have been hidden in averages.

For the annotated version, highlighting where their observations can be seen:

annonated_example.png

The Performance Spectrum component is configured by selecting an event log from your Knowledge Model. 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, define the sequence that you want to analyze

    The Performance Spectrum visualizes all cases matching a defined process sequence. You can customize this sequence by:

    • Adding or removing events:

      remove_event.gif
    • Defining connection types between events:

      • 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.