Stay up to date on the latest product updates, customer stories, and industry news from Redpoint. Opt-in and select the topics you'd like to learn more about!
Redpoint Interaction v7.x Documentation
Redpoint Interaction v7.x Documentation
Breadcrumbs

Admin: Configuring workflow prioritization

Overview

The following settings facilitate the setup of 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"

  • enabled: the master switch for queuing/prioritization. In the Helm chart this already defaults to true.

  • maxConcurrentWorkflowActivities: the maximum number of interactions allowed to run at the same time (default is 100). Despite "Activities" in the name, this counts whole running interactions, not steps within one, so a 1 would mean one interaction at a time.

  • maximumQueueTime: a safety valve: how long an interaction may wait in the queue before it's released regardless of the limit (default 24 hours). We recommend increasing this value if your interactions can back 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.