Ensuring that Workflow Runs can complete as expected.

Getting services to talk to each other

When you are creating workflows to send data between services there are a few concepts to be aware of when it comes to interoperability - the ability of two services to talk to each other. Workflows at Primer are a translation layer between these services and due to the defined contracts for Inputs and Outputs, data can flow freely without much overhead of having to map or convert data yourself.

With that in mind, it's almost inevitable that at some point the wrong data could be send to a service, making it impossible for that service to do its designated job.

Validation during workflow creation can help you identify these situations early, but can never be an exhaustive preventive measure. In case of problems, the full details of data exchanged between services or error messages received are viewable in the Workflow Run details.

Necessary steps

Before you publish your workflow, we validate that all blocks are properly configured. Any incomplete blocks are highlighted so that you can apply the necessary fixes.

Types of validation

Required vs optional fields

Any Action or Utility might have a minimum required set of information to be set up in order to be able to publish a workflow.

You can identify incomplete Actions easily, as some Inputs are marked as mandatory:

Data type validation

Any input, be it for a condition, an action, or other utilities, is defined by a data type. This could be a number, a text string, a list of pre-defined values, a date, or even very specific inputs, like e-mail, or web addresses.

Primer supports setting up workflows by manually selecting or entering values, as well as mapping previous values to a field, such as using the payment customer phone number as the recipient number for an Action sending SMS.

When manually entering values, you can see hints in case the input is not valid, such as this invalid e-mail address:

Validation will only help partially when mapping fields from previous blocks, as the actual value to be passed is only known when the workflow runs. Here is an example of a customer's e-mail address from the payment created trigger being assigned to the recipient field of a send e-mail action:

Some fields from previous blocks are incompatible with the input you are setting up, so you might not always see all outputs in the variable selector. For example it is not possible to map a text field like "customer name" to an amount field, or a currency to a country field. These fields will therefore not show up in the variable selector for that field.

However, some ambiguity is allowed to enable more flexible workflows. It is possible to map a text output to an e-mail field in case the source app has not explicitly defined a field as "text in e-mail format", but only as "text". This increases compatibility between some services where not all data types are always defined as explicit as they could be. Should a workflow encounter problems due to this, you can see which values have been passed and what the third-party response was in the workflow run details.

Blocks without an app connected

It is possible to create a workflow without actually having connected to the apps yet. This way you can start exploring automation use cases or discover an app's capabilities without having to have the app set up yet. However, in order to be able to publish your workflow, you have to connect to the app. This is possible right from the canvas by setting up the account from there.

Input with missing source

Any value that is assigned to an input keeps a reference to its source block. If that source block is removed, moved, or updated so that this field is no longer available, then you will see a validation hint telling you that this field is no longer available at this step. You can remove that field and revisit what else you need to update to proceed.

Optional app updates

Some validation hints are even optional, such as when there is an app update available, but you don't have to update to the latest version in order to publish your draft.

What is not being validated

Validation will help you avoid the most obvious mistakes when creating workflows, because they are objectively wrong. On the other hand, it is possible to set up workflows that satisfy all the requirements of the workflow builder but still result in problems. This is where the workflow run details come in handy as they allow you to debug exactly what has happened.

Consider a workflow that cancels an order after a fraud check. It could be that the order is actually not known to the service itself due to some other steps missing, like the order creation. When you create your workflow and the individual blocks are set up correctly you can publish the workflow. But when the workflow is running, the third-party might respond with "I don't know order-123". This is when you should revisit your logic and workflows holistically and ensure that orders are actually created with that third-party prior to any cancellation attempt.

Start automating

Now that you know how to reliably create workflows, check out our guide to monitor workflows, or learn more about workflows best practices.