2 minutes to read

Documentation for triggers, running workflow executions

Table of contents


Triggers are the operators used to execute a workflow automatically. They are connected to a actions within workflows - often the starting node. Triggers usually take an execution argument that will be used to execute the workflow in question.


Triggers, along side apps and variables, can be found on the left hand side, in a tab called "Triggers".


Triggers are developed by Shuffle specifically to give the user access to multiple ways to run a workflow. The triggers that are not available on-premises are due to access requirements - not hiding of features.

There are currently four triggers, with a fifth "hidden" one:

  • Webhook - Handle realtime HTTP requests from anywhere.
  • Schedule - Runs your workflow on a schedule. Cronjob or seconds.
  • User Input - Waits for user input before continuing. You can answer yes/no.
  • Subflow - Allows running of another workflow from the current workflow.
  • Email - When you get an email in gmail/office365: start the workflow
  • Rest API - Essentially a trigger from either: 1. Another workflow. 2. Any third party software

There are currently six ways to execute workflows:

  • Cloud & Hybrid (paid): Webhook, Subflow, User Input, Schedule, Outlook, Gmail, Rest API
  • Onprem: Webhook, Subflow, User Input, Schedule, Rest API


ALL triggers are available EVERYWHERE if you have a Shuffle subscription. This further allows routing executions through cloud (without saving any data) to your open source instance, without the need to open for inbound requests in your firewall(s).

Example: Say you want to get messages from a service like a SIEM, but it's in a different data center. How do you get that request all the way to your instance? This can be done by setting up cloud synchronization allowing for: 1. Remote SIEM -> Send Webhook to as a "proxy" 2. Your local instance looks for jobs from an organization you own on 3. When a webhook job is found on - it will execute in your local instance.

Read more about cloud synchronization in the organization documentation.

Finding executions

When a trigger runs, you will NOT be notified about it anywhere. It will instead run behind the scenes. You can however discover their data and executions by going to the specific workflow's UI, then clicking "See all executions" on the bottom (the running person).


Webhooks are the real-time handler for Shuffle data. Webhooks were initially implemented to handle data from Office365 connectors and TheHive, but have turned into a generic trigger, taking any kind of HTTP data, as we saw the need for it.

HTTP Method(s):

  • GET
  • POST

PS: Data in the POST request will be the execution argument. If HTTP queries are present, these will be converted to JSON.


In later versions of Shuffle, you further have access to an authentication field. This field is based on the headers of the request, and any header added to this field will be REQUIRED from the sender of the webhook.

One header for each line. In the image below, the request would need to contain the headers "authorization" and "authorization2" with the exact valus specified. Triggers-view-6

Webhook Example

To start using webhooks, you should have a service that supports webhooks (e.g. the two above mentioned). If you just want to test, you can also use cron.

Once you have a service ready: 1. Drag the "Webhook" trigger from the left hand side into the main view, and you should see it automatically connect to your starting node. 2. Click "start" to deploy this webhook (it might be auto-started). This will also be stopped if you remove the node or the workflow. A webhook can not be in multiple workflows, but you can deploy as many as you want. 3. Find your webhook URI in the "Webhook URI" window, and copy it to your service


Test it! Say your URI is: and you want to use {"test": "testing"} in your workflow:

curl -XPOST --data '{"test": "testing"}'


Subflows is a trigger made to run workflows within other workflows. There's further a "parent/child" element to it where there's always a reference to where the execution came from. This can also run a subflow within itself or be recursive (infinite loops).

Purposes we'll cover:

  • Create standard workflows that can be used within other workflows. E.g. checking an IoC in a standardized way every time.
  • Handle loops well. This is to avoid multiple nested for-loops and instead make a new workflow to handle it. E.g. list of emails with list of attachments with list of sub-attachments (e.g. Zip).


  • shuffle-subflow app. This is automatically installed.

Here are the known missing features for subflows

Extra subflow information

  • Subflows can be in the same Workflow. When selecting, it will show up as red.


  • Parent nodes of the subflow trigger show up as red. When using these, make sure you stop the workflow. We will add a warning for this, as it can run you out of resources easily.


  • After choosing a subflow - if you right-click the subflow node in the workflow UI, it will import the subflow. When saving, this will NOT be a part of the workflow.
  • PS: We will make this part of the workflow visual and non-interactive at a later stage.


Subflow Example

  1. Drag a subflow into the PARENT view from the left side and click it Triggers-subflow-1

  2. Choose a workflow to run. This will use the STARTNODE as default, which can be changed. The red workflow is the one you're currently working on. Triggers-subflow-2

  3. We'll decide a startnode and the information to send to the subflow. In our case, we'll use the list below, and send one item at a time with the IP to be searched for in Virustotal. The data with the list is named Repeat_list in our case, hence we use $Repeat_list.#

[{"ip": "", "malicious": true}, {"ip": "", "malicious": false}, {"ip": "", "malicious": true}]


  1. It's time we explore the results. In total, this should execute FOUR times: 1 for the first workflow and once for EACH of the objects in the list. Triggers-subflow-4

  2. Here's a view of the total workflows. Notice how three of them have a different icon? This is because they are subflows. PS: It will always show the maximum amount of nodes in the workflow, whether it's a subflow or not. Triggers-subflow-5

  3. Exploring the subflows, we find that the IP's have been searched for in Virustotal, and that we have a reference to the parent. Clicking the reference will take you to the parent execution. Triggers-subflow-6


On-prem Schedules on-prem are ran on the webserver itself. Rather than cron, it uses a scheduler that runs it every X seconds. This will become more sophisticated over time. Schedules persists in the database even when you turn off Shuffle, so don't be afraid to update.

Cloud Schedules are based on google's cloud scheduler and are schedules that run based on cron. It takes two arguments - the schedule you want to run it on and the Execution argument used in the workflow. A simple cron converter can be found here. When you are ready to run, click "start".

Schedule Example

  1. Drag a schedule into the view from the left side
  2. Click the schedule
  3. Type in the amount of seconds between execution (down to every 1 second)
  4. Type the execution argument you want to execute with. This can be used by actions.
  5. Click "Start"


User input

The user input node is a way to temporarily pause an execution until someone MANUALLY clicks something. This can currently be through Email and SMS, but we will introduce many other options, including chat systems and running other workflows.

The point of the node is to wait for manual approval before running some automation. E.g. management approval for new scan schedule. E.g. analyst approval for cleanup up a host.

User input node Shuffle

  • Email - What emails do you want to send the workflow information to?
  • SMS - What numbers do you want to send the workflow information to?

When the email/sms is sent, it will look like the image below. We will optimize this over time to reflect everything from Shuffle, but during our initial proof of concept, this is for you to understand. You will get to answer: yes or no? If you answer yes, the workflow execution will continue from where it left off. If you answer no, it will be stopped. This action can be sent to multiple people, but the link will only work once. User input email Shuffle


TBD: This has been made to work with both cloud and hybrid version of Shuffle. Can't work 100% onprem because webhooks from Office365 and Google Workspaces can't reach your host.