Open Navigation

Automated workflow testing

Introduction

Before deploying workflows, it is important to test them to make sure any errors are removed before affecting live systems.

We can break this process down into the following main steps, assuming your workflow uses a webhook or service trigger.

  1. Replace the trigger in the workflow of interest with a Callable trigger, and place the service trigger in a new workflow. This means that your main workflow will be able to recieve data from both the service trigger, and your scheduled test

  2. Determine a test payload that can be used to trigger the workflow.

  3. Create another workflow that uses the Scheduled trigger, and uses the test payload determined in step 2 to trigger the main workflow.

  4. (Optional) Add some error handling logic to your main workflow

  5. (Optional) Configure the main workflow so as to undo any effects from testing

In the following example, we will be using a workflow that is triggered by a contact creation event in Salesforce. Please see our Salesforce Trigger documentation for instructions on how the trigger works.

Imagine the following 'Salesforce Trigger Example' workflow, which has a Salesforce trigger and performs a synchronisation to another system, in this case Netsuite:

testing-workflow-1

For the purposes of this guide don't worry about the details of the Transformation logic step here. It is there as a placeholder for any data processing that might need carried out before e.g. a new contact is pushed to Netsuite. In the case of Salesforce you would have to use a 'Find Record' operation which uses the id obtained from the trigger to pull the account which matches the id supplied by the trigger payload.

Step 1 - Change the workflow to a callable trigger

The first step is to change the trigger of your main workflow to a Callable Trigger so that it is available for the other workflows to call:

change-to-callable-trigger

Step 2 - Move the service trigger to a new workflow

Now create a new workflow, with the Salesforce trigger (i.e. the same as was being used in the original workflow):

salesforce-trigger-1

Then add a Call workflow step to the workflow. Set the Workflow field to reference the 'Salesforce Trigger Example' workflow from the first screenshot above. Then set the value of Data to be a jsonpath referencing the output of the trigger step: $.steps.trigger:

call-workflow-1

Once setup correctly be sure to enable your workflow:

enable-workflow

With this setup, your workflow will work in exactly the same way as before, there are just a couple of additional steps in between.

To test this workflow, we can set up a workflow to mock contact creation in Salesforce.

Step 3 - Determine a test payload

By enabling the workflow we just created above, and then creating a new contact in Salesforce, we can inspect the debug output and see the JSON that is available from the trigger output. In Salesforce this is very simple:

salesforce-trigger-output

So we can see that when a contact is created in Salesforce, we are told its Id, and an events property is included as this is how multiple contacts from Salesforce may come through at the same time

Now that we know the format of the payloads that will be received by your workflow, we can manually create a test payload that doesn't rely on an actual action in Salesforce to trigger the workflow being tested.

Step 4 - Create a new scheduled workflow to send the test payload

We now create a third workflow, which has a Scheduled trigger. This trigger will allow us to automate the testing, by letting us run this workflow in the background. We set this to run every day, so that the testing is not triggered too frequently.

Then to generate the mock data we add an Object helpers step, with the operation set to 'JSON Parse'. Paste the JSON from above into the Text field. In addition, we add a new property to this payload called 'testing', and set its value to true.

This allows us to track the payload through the main workflow and can add any additional logic (i.e. to rollback/undo action taken based on the test payload):

object-helpers-1

Then we add the Call workflow step, with the default 'Fire and forget' operation. We set the 'Workflow' field to 'Salesforce trigger example' - as before. In 'Data' we enter a jsonpath referencing the output from the Object helpers step:

testing-workflow-2

This is now ready to be enabled, which will start the automated triggering of the contact creation workflow.

Step 5 - pull the data from the Callable trigger

Now in your main workflow you can set any steps, such as a script connector step, to pull the data from the callable trigger so as to carry out any necessary processing/transformation. This is done by using steps.trigger. jsonpaths:

pull-callable-trigger-data

(Optional) Step 6 - Set up the main workflow to undo any effects of testing

In our example workflow, we are adding the contact from Salesforce to Netsuite. As this is a testing workflow which will run regularly, we may want to add a set of steps that delete the contact from Netsuite, if we are testing.

This is where the "testing": true property we sent through with the payload comes in handy. In our main workflow, we can add a step from the Boolean condition connector, with the operation set to Property exists, and set the value of JSONPath Property to $.steps.trigger.testing:

testing-workflow-3

In the true branch of the condition, we can then add a step to delete the contact, so that it can be re-added next time the test payload is run.

(Optional) Step 7 - Add some error handling logic

As per the instructions set out in our guide to Error Handling you can add some logic to deal with any errors that might be thrown when making test calls to the services involved in your workflow.

This could be a simple alternative 'error' pathway:

optional-error-handling

Or it could be a more granular alerting workflow setup, as detailed in the above link.

Please note there is a separate alerting worklow setup for our Embedded customers.

Was this article helpful?
Yes
No