Shuffle workflow triggers and human approvals

A Shuffle workflow starts when a trigger sends a request to the server, and the path from that request to an approval pause runs through three server-side components you should be able to name before go-live. The frontend hosts the editor and the interface analysts use to review and answer pending steps. Behind it sits the Go backend API, which listens on port 5001, receives webhook calls, schedule events and subflow calls, and records each execution. The backend stores workflow definitions and execution documents in OpenSearch, the document database on the server side. When you size or back up a deployment, the OpenSearch data is what holds the record of what ran and what is waiting.

The runtime side is Orborus. It polls the backend for queued jobs, and for each workflow execution it starts a worker. The worker then starts the app containers that the workflow's actions need, using the versioned Docker images for each app. This split drives placement decisions. In a hybrid setup, Shuffle Cloud hosts the frontend and backend while a local Orborus runs inside your network and needs no inbound firewall ports, so actions that touch internal systems run where those systems are reachable. Ask which Orborus node picks up each job, and document the location of every node in your design. The high availability guidance recommends more than one Orborus node so a failed node does not stop running workflows, but test how a job is reassigned before you rely on it.

A user input step is where the run stops and waits for a person. The step sends a prompt, typically to a channel or app the analyst watches, and the execution stays open until someone responds or the step ends. Several points need confirmation in the documentation for your version and in a test environment. Confirm whether the waiting state is written to OpenSearch, whether any part of it depends on a worker still running, and what happens to a paused run when Orborus or the backend restarts during the wait. Also confirm how a response that arrives after the step's timeout is handled. Run a deliberate restart in the middle of a test approval before any production trigger uses the step.

Settle three decisions around the pause before you choose the trigger type. First, define who can answer an approval and confirm that each response is tied to an identity you can audit. Second, decide how long a containment request can wait and what the playbook does on no response, based on the timeout behavior you have verified. Third, keep the SHUFFLE_ENCRYPTION_MODIFIER value unchanged across restores, since the docs warn that changing it breaks saved app authentications that resumed steps depend on. The apps that deliver the approval prompt also rely on their own stored credentials, so include them in the same test run.

The cost of a triggered or approval-gated playbook in Shuffle is set by app runs, the single metric in its licensing. Shuffle's pricing article defines an app run as an action that actually executes in a workflow. Triggers are not counted, skipped actions are not counted, and users, apps and workflows are unlimited. That means the planning question is not how many alerts or webhook calls arrive, but how many executed actions each arrival causes. A webhook that fires often costs little if the first step filters most events out before any app action runs. Before you estimate, ask your Shuffle contact to confirm how a user input step is counted when the workflow pauses and later resumes, because the pricing article describes the metric in general terms.

Design choices decide the run volume. A schedule trigger is free on its own, but every scheduled execution that reaches an app action adds runs. A poll that returns nothing and ends at a condition costs little. A poll that enriches every returned record with several app calls costs a great deal. Fan-out subflows multiply the count: one parent run that starts a subflow for each indicator, host or user turns one execution into many. Steps that run on every alert change have the same effect when an alert is updated several times during its life. Enrichment that re-runs on each update, with no check for what changed, can multiply runs without adding any analyst value. Illustratively, an alert that updates five times and triggers four enrichment actions each time produces twenty executed actions from one alert.

Approval gates shape the count in a different way. A user input step pauses the workflow until an analyst responds. The pause itself is not an executed action, but the actions placed after approval are. Place containment steps after the approval point, and keep low-risk enrichment before it so that analysts are not waiting on repeated lookups. Decide whether one approval should cover a batch of items or whether each item needs its own gate. A batch gate usually produces fewer, larger runs. A per-item gate produces many small runs, each with its own app calls. Test the gate with a resumed execution in a non-production instance and read the execution history to see which actions ran and how often.

Edition limits are the other variable. Shuffle states that all features are available in the open-source edition, and that since v2.1.1 the limits between the open-source and enterprise editions are actively enforced. Shuffle also stopped supporting versions older than v2.1.1 after January 31, 2026. A design that ran comfortably on an older build may therefore meet an enforced limit after an upgrade. Confirm which edition's limits apply to your planned volume, using the configuration documentation and your licensing terms, and check the limits against the release you intend to deploy, not the one you tested on. The latest Docker tag is the recommended stable option, and the nightly tag carries experimental changes that may alter behavior.

Before you request a quote, build a run-volume estimate from the workflow graph. For each trigger, count the executed actions under expected and peak alert rates, mark every fan-out subflow and every step that re-runs on alert change, and note which steps sit before and after each approval gate. Ask the implementer to show where deduplication, conditions and change checks reduce the count. Ask for the edition and its enforced limits in writing, how run volume is reported to you, and how the design will be retested after each upgrade. Because runs recur every day the workflow operates, this cost is ongoing, and it should be reviewed whenever alert volume, the number of enrichment sources or the approval process changes.

Scheduled runs and paused approvals keep working through a node failure only if the high-availability layer under Shuffle is built and tested. Shuffle's documented guidance has five parts: an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when several backends run, the backend and frontend scaled across all servers, and more than one Orborus node. Each part removes a single point of failure. Read the guidance as a set, because a clustered OpenSearch layer with one Orborus node still leaves runtime work with no fallback.

Schedules and approvals depend on this layer for different reasons. Orborus polls the backend for jobs and starts a worker for each workflow execution, so if the only Orborus node is down, no new scheduled run starts and any run it was executing may stop. A user input step waits for an analyst, and that waiting state is held with the workflow execution in the OpenSearch document database. If the cluster loses that data, or the backend that resumes the execution cannot reach it, the approval may be lost or fail. Confirm in your Shuffle version exactly where paused state is stored and how it resumes.

Several design decisions follow from this. Decide how many Orborus nodes you need and place them on separate hosts or failure domains so one outage does not stop all runtime work. Decide whether your NFS export is itself a single point of failure, and whether its backup and recovery match your approval timelines. Set OpenSearch replication and snapshot backups for the indexes that hold workflow executions. Make sure every scaled backend uses the same SHUFFLE_ENCRYPTION_MODIFIER value, because the documentation warns that losing or changing it breaks all saved app authentications. Memcached is optional, so decide whether your load justifies it before adding it.

Before relying on this design, test failover of the two cases that matter most. First, start a workflow that pauses at a user input step, stop the Orborus node that is running it, and confirm the approval still appears, can be answered, and lets the workflow finish. Second, set a schedule to fire while one Orborus node is down, and confirm the run starts once, completes, and records its result. Repeat both tests after stopping a backend instance and an OpenSearch node. Record what happened, including delays and any manual steps, and repeat the tests after each upgrade. Use these results to set the expectations you give analysts and the owners of time-sensitive playbooks.