Building and Testing Workflows

The Workflow Studio consists of the following parts:

  • Name - your identifier for the workflow
  • Notes - a place for notes, also used to adjust workflow timing
  • Tags & Triggers - how your workflow starts to run
  • Modules - data processing modules
  • Outputs - where to output data from the workflow
  • Debugger - logs and debugging tools
  • Revisions - version control

You can see each part in the image below. We will also go into more detail about each part.



Building your workflow

To build your workflow, you'll need tags & triggers, modules, and optional outputs. Each of these components are dragged & dropped from the side menu onto the canvas.

Tags & Triggers

The first component of a workflow are the tags & triggers. These allow you to signify when you want your workflow to run. Workflows can be triggered based on when data arrives with a specific tag or on a timed schedule. An example would be a location tag from the raw stream.

After being dragged onto the canvas, it would look like this:


This box connects to your module and signifies that your workflow will be triggered whenever data is sent with a 'data.sample.location' key in the raw stream, regardless of the value.


The star on the front of the tag name indicates that the block is a trigger. You can double click on the box to bring up the tag settings. From there, you can uncheck the trigger box to disable it. When disabled, the data for this tag will still be provided to the module for you to use, but incoming data for this tag will not trigger it for execution.


Schedulers are other types of triggers based on a timer, such as Daily (i.e. Daily at 12AM), Hourly, and Custom (i.e. every 5 minutes). The Schedulers have settings that need to be set by double-clicking the block before it can be used. You can specify which users the trigger will affect as well as the time zone.


Programmatic Modules

The second component of a workflow is the Module. This is the main component of a workflow and processes the data.


Default Base Python Module

To do your own python customization, you can use the ‘Base Python’ module listed under the ‘Foundation’. For more on Python, visit the Python 2.7 documentation

When double-clicked, you will find a default script that sets the output as the input from your trigger:

# set output to input
IONode.set_output('out1', {"value": IONode.get_input('in1')['event_data']['value']})

Note: This would cause an error if your trigger is a scheduler trigger since there is no input.

  • IONode.get_input('in1')['event_data']['value'] calls the IONode class that references the inputs and outputs, requests the input 'in1' (the default name of the 1st input node). 
  • IONode.get_input('in1')returns: {'tag_name': 'raw.value', 'event_data': {'value': 'data'}, 'trigger': True, u'observed_at': '2016-09-29T23:45:10Z'}
  • The call to IONode.get_input('in1')['event_data']['value'] therefore returns the data only for the tag.


The default script is just to get you started but you can add your own customization. These are some basic functions that you can also use in your Base Python Modules:

 Function Result 
log(value) OR print value    Returns a value in your debug logs
Note: Debug log must be enabled to capture this
escape() Exits a Workflow


Medium One also provides many libraries for use in the modules, which you can find in the "Workflow Libraries" section. These libraries can send emails, process location data, and more.


In addition to the Base Python module, Medium One also provides pre-programmed modules in the Modules pane to help you get started.



A module can take multiple inputs and outputs. Select the number of inputs and outputs needed with Inputs/Outputs.



Input data can then be referred to with the IONode.get_input('') call as mentioned in the previous section.

Shortcut Keys

There are also workflow shortcut keys that you can use in Workflow Studio

Shortcut  Result
CTRL + S     Save
CTRL + C Copy
CTRL + V Paste
CTRL + Z Undo
CTRL + / Comment/Uncomment



The last component of a workflow is the output. The output is optional and only if you want to produce a processed event in the Medium One platform. An example where you wouldn’t need an output would be sending the processed data as an email to yourself. However, in many circumstances, you may want to create a new event in one of your processed streams. 


When you drag an output onto your workflow and connect it to the modules, your workflow will be expecting an output. Check out the IONode Library documentation to learn how to send your data to the outputs.


Saving + testing the workflow


So now that you’ve created a workflow, you want to activate it. Activating a workflow simply means to make it ‘live’. Immediately after activation, any event sent in with the tag trigger will go through the data processing module.

To activate your workflow, go to the Revisions pane and click the checkmark icon next to the latest revision (on the top). Afterward, it should look like this:


As you are creating your workflow, you may want to go back to a previous version. This is where revisions come into place. On the Revisions pane, you can see all the revisions you have made, auto-saved after every change you make. Here, you can see different options for each revision:

  • Restore  - Go back to a previous version as a working copy. This will create a new revision with the same configuration as the restored one.
  • Activate - Make a workflow go live.
  • Deactivate  - Make a workflow no longer live.
  • Favorite  - Save a workflow as a favorite. The revision then cannot be deleted and it will always show up on the revisions pane. A revision is automatically favorited upon activation. To unfavorite, click the icon again. The maximum number of favorited revisions is 20.
  • Delete  - Delete a revision.
  • Clone  - Clone a revision to a new workflow.

In addition to those options, You can also rename a revision by clicking on the default name “Autosave-x”.


After finishing your workflow, you may want to test it to make sure it is working as expected. To do this, open the debugger pane.

The Debugger tool allows you to simulate sending events and viewing the output to verify if it is correct. Here is a standard example of how to test your workflow:

  1. Make sure the correct revision of your workflow is activated.
  2. Turn on the debugger by switching it on. Note: This uses 1 workflow credit every time the workflow is triggered.
  3. Simulate the event. Select the stream and user you want to send the event to, then specify the event in JSON format. {"<trigger_tag_name>": <value>}
  4. Push the Send button to send the event. This does not use any event credits but it does use a workflow credit. 
  5. View the event. After sending the simulated event, hit the refresh button next to the “Last 10 logs”. You should see a new log show up.
  6. Click “display” and the input and output values should be shown on the Workflow Studio canvas. You can also click the timestamp for a popup with your debug log.
  7. Analyze results. If the output is what you expected, then you are done. If not, you may need to do a few tweaks then try the debugger again.

Note that any events sent through the debugger will trigger all workflows triggered by that tag, not just the one you are testing.