Admin: Configuring 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.

Use the following settings to set up workflow prioritization in the Helm chart. Refer to the RPI Reference guide for details on using the prioritization feature in the Interaction Designer.

Configuring workflow prioritization in Helm

If your tenant is RPI hosted, please submit a ticket to Support to assist with these changes.

In order to use the prioritization feature in RPI, you’ll need to configure these settings in Helm.

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

Setting	Default	What it does
`enabled`	`true`	Master switch for queuing/prioritization. On by default; set to `false` only to disable the feature.
`maxConcurrentWorkflowActivities`	`100`	Maximum number of interactions allowed to run at the same time. This is the value that does the real work. Despite "Activities" in the name, it counts whole running interactions, not steps within one.
`maximumQueueTime`	`"24:00:00"`	How long an interaction may wait in the queue before it is released regardless of the limit. Raise it if interactions can in your tenant get backed up for longer than a day.

You won't find jobExecution/workflowPrioritization in the sample values.yaml, as that file only shows the common options. As per the chart's guidance, you override any setting by placing it under the matching top-level key (executionservice) in your own overrides file, exactly as above. You can browse every available key and its default in the Reference tab of the RPI Helm Assistant.
Behind the scenes the chart renders these into environment variables on the ExecutionService pod (RPIExecution__WorkflowPrioritization__Enabled, etc.), which is why there's no appsettings.json to edit; the Helm values are the correct, durable place to set this.

To apply the settings above, add the block to your overrides and run your usual helm upgrade (or let Argo CD / Flux sync it if you're on GitOps). The ExecutionService pod restarts with the new settings and the limit takes effect immediately.

The concurrency limit is applied per tenant, not globally across the whole installation. For a single-tenant setup this is exactly "one at a time." If you need a single global limit across multiple tenants, please reach out to Support.