Use cases: Workflow prioritization

Overview

Workflow prioritization lets you control how many interactions run at the same time and, once that limit is reached, which ones run first. It’s useful whenever unmanaged concurrency causes a problem; either too many workflows hitting the database at once, or overlapping workflows undermining a per-contact rule.

The video below reviews workflow prioritization and walks through how to use the prioritization feature in the Interaction Designer.

This topic includes two example use cases of this feature:

• Limit to one workflow at a time: enforce a per-contact frequency rule (e.g., no more than one message per person per day). This is best if you run a low volume of workflows daily. Check out the first use case for details.

• Throttle database load: use workflow prioritization to cap concurrency so a surge (especially right after a maintenance window) doesn't overwhelm the database, and lets critical sends jump the queue. Refer to the second use case to learn more.

The section below explains how the feature works; the two use cases then show it in practice.

How it works

In order to use the workflow prioritization feature, you’ll need to set up two parts that work together:

• Cap the concurrency in Helm (the back end): the environment sets the maximum number of interactions allowed to run at once. This is configured in the deployment's Helm values and is turned on by default with a cap of 100.

• Set up per-interaction priority (in RPI): for each interaction, use the Prioritization tab on a trigger to set that workflow's priority to Urgent, Normal, or Low (plus queue-time and maintenance overrides).

Configuring the concurrency cap

Because the feature is turned on by default, you only need to access these settings to change the cap or turn off the feature. The settings live under the executionservice key in your Helm overrides:

executionservice:
  jobExecution:
    workflowPrioritization:
      enabled: true
      maxConcurrentWorkflowActivities: 1
      maximumQueueTime: "24:00:00"

The cap is applied per tenant, not globally across the whole installation. Because these are back-end settings, they are applied by cloud engineering; on a client-hosted deployment, the client's own cloud-engineering team makes the change. After the values are applied (helm upgrade or a GitOps sync), the ExecutionService restarts and the new cap takes effect immediately.

How queuing and priority behave at runtime

• If the cap is never reached, all triggered interactions simply run concurrently; priority has no effect until the limit is hit.

• When the cap is reached, a newly triggered interaction is placed in a Queued state instead of running immediately.

• As running interactions finish, queued ones are released. At equal priority, queued items are released in scheduled-date order (first-come-first-served).

• Urgent interactions bypass the queue and run immediately, even when the limit is reached; reserve this for genuinely time-critical work.

• An Urgent Deadline can auto-promote a Normal/Low interaction to Urgent at a set time.

A useful mental model: the cap creates the constraint; priority decides who wins under that constraint. If everything can run at once, priority has nothing to act on.

Use Case 1: Limit execution to one workflow at a time (frequency capping)

When to use it

When you need to enforce a per-contact frequency rule. For example, ensuring no individual receives more than one message per day and overlapping workflows would otherwise undermine it.

Why it works

When multiple workflows fire simultaneously, a frequency or suppression rule can't be reliably enforced: two workflows could each send before either checks the rule. Limiting execution to one interaction at a time means each run completes its validation ("has this person already been messaged today?") before the next begins, so the rule holds.

What to configure

Set maxConcurrentWorkflowActivities: 1 in the Helm chart. In RPI, priorities can be left at the default Normal; serialization itself does the work, and queued items run first-come-first-served.

Use Case 2: Throttle database load (especially after a maintenance window)

When to use it

When you have a large number of workflows that fire at once and overwhelm the database or RPI server. This is most acute right after a maintenance window: when RPI is paused and then resumed, everything held or scheduled during the window tends to fire at the same time. The same overload occurs in any high-volume environment running hundreds of workflows in a tight window.

Why it works

Lowering the concurrency cap from its default of 100 to a number the environment can sustain lets RPI throttle itself on resume (and in general) instead of running everything simultaneously. Within that cap, priority then lets you:

• Order the queue so more important workflows run sooner (Normal vs. Low), and let smaller low-priority tasks through rather than blocking them wholesale.

• Flag mission-critical workflows as Urgent so they bypass the queue entirely (e.g., a purchase or shipping confirmation that must go out regardless of how many campaigns are queued behind it).

What to configure

Lower maxConcurrentWorkflowActivities to a sustainable value in the Helm chart (see Sizing the cap), leave standard campaigns at Normal/Low, and set genuinely time-critical workflows to Urgent. If you are managing around scheduled maintenance, combine this with the Maintenance Mode Buffer settings on the Prioritization tab in RPI, which control how far ahead of a maintenance window activities are placed on the wait queue; the wind-down complement to the cap's throttled ramp-up afterward.

Sizing the cap

There is no universal number. The right cap depends on the environment and its constraints — database capacity, server headroom, and the shape of the surge. Arrive at it iteratively:

• Observe under the worst case: when coming out of a maintenance window (when the backlog fires at once), watch active database queries and DB/server load as workflows resume.

• Find the breaking point: identify the level of concurrent activity at which load becomes too much.

• Reduce the cap: lower maxConcurrentWorkflowActivities so fewer interactions run at once.

• Re-test and repeat: observe again under the same conditions and adjust until load stays within the environment's limits without starving throughput more than necessary.

The result is tuned to that specific environment; revisit it if the workload profile or infrastructure changes.

Prioritization tab fields

The fields on the Prioritization tab and how they relate to the behavior above:

Quick reference

Additional references

• RPI Reference guide: Prioritization tab

• RPI Helm Assistant (back-end configuration keys and defaults)

• RPI Admin guide: Configuring workflow prioritization

Last updated: September 04, 2026