Automating your use cases with Primer is very powerful, and flexible. You can build almost anything without a line of code. Like any open tool, Automation comes with its own set of dos and don’ts. Mastering them will make your workflows more resilient, more efficient, and easier to maintain.

Our recommendations on how to set up Workflows in the most efficient way possible depend greatly on your use cases.

This page introduces some of what we consider best practices when building workflows - and outlines why we think these proposals are more beneficial than the alternative.

Create more granular workflows

With all the tools available to create sophisticated workflows, you might be tempted to create big workflows achieving many tasks in one go. While this is technically possible, it will become cumbersome to maintain and potentially introduces a lot of redundancy when you have to repeat certain steps.

Workflows give you many tools to have more granular workflows based on use cases:

• Apps will emit events as Triggers which you can react to in a workflow.
• When you create multiple workflows based on the same Trigger, the Trigger Conditions can ensure only certain conditions actually start a workflow.

Reduce redundancy

When you set up a payment flow that includes multiple routes, every time you authorize a payment for that route, you can set the “Authorize payment” action up in the best way possible to ensure payment success.

However, once the action performed its assigned task, then you would need to check if the payment was authorized or declined before adding the “Capture payment” action.

This can be simplified by splitting the workflow into two:

1. 1
   one workflow to authorize payments
2. 2
   and one to capture payments that have been authorized

Authorize payments: Use the Conditions Utility to route to the required processor.

Then create a workflow based on the “Payment status updated” trigger. Here there are two options to react to the payment status update to capture the payment if the status is Authorized:

1: Adding the Conditions Utility to check for “Payment Status = Authorized" before adding the “Capture Payment” block. If you don't check for Authorized, then a capture attempt would be made for any payment status change, of which there are many.

or 2: Using the Trigger Conditions

The Trigger Conditions allow you to set conditions that determine if a workflow should even be started. Only if the triggering event and the conditions that were set on the Trigger are met your workflow will start executing.

This needs to be done very carefully, as otherwise you are risking starting more than one workflow if the set-up is not explicit enough, or no workflows if the set-up is too restrictive.

Set the trigger up with a condition for “Payment status = Authorized” and add “Capture payment” as the first and only block. This will now capture every payment that was authorized.

These principles apply for non-payment workflows as well. If you react to an order being created, you could react to a specific flag only, or create multiple conditions within the workflow if you want to handle more than one use case.

Flexibility

The aforementioned examples are not mutually exclusive, but can be combined based on use cases to allow for greater flexibility.

An example would be if you want to create a support ticket for declined payments, and post failed payments into a Slack channel. Here you can either create two workflows, one with a Trigger Condition each (”Status=Declined”, “Status=Failed”) or combine them into one workflow for “Error handling” with the Trigger Condition being “Status one of Declined, Failed".

If you do the latter, then you can still add the condition builder and create one route for “Status = Declined", and one route for “Status = Failed". It's best to keep the conditions explicit like that, and just keep the “all other conditions” block unmapped for better readability of the workflow.

Handle third-party issues

Let’s consider a workflow using the “Post message to channel” action from Slack. During the execution of the workflow, anything but Slack successfully posting the message will result in a stop of the workflow execution at this block and result in a Failed Workflow Run.

In case of failures, the Workflow Runs can be used to troubleshoot. Actions do not return a response status in the Outputs, which means that we assume that all Actions are running without issue.

If Slack did not post the message successfully then you can look at the Workflow Runs. Within the timeline you will be able to identify if the Action was not successful due to invalid credentials, or any other possible configuration issue by opening the details for each event. See monitor workflows for more details on the Workflow Run details.

The assumption of an Action being successful will allow you to chain multiple actions together, for example in a flow like this, where a ticket is created via Zendesk and then posted to Slack:

If the “Create ticket” Action fails, the whole Workflow Run will be marked as Failed and no Slack message will be posted.

Workflow vs object status

Keep in mind that an app Action can manipulate objects, for example the “Authorize payment” Action can lead to a new payment status, whereas third-parties can avail actions to manipulate their objects, for example:

• “Update customer” Action updating a customer status from PENDING_REVIEW to APPROVED
• “Update order” Action updating an order status from DISPATCHED to FULFILLED
• “Confirm shipping” Action returning an updated shipping status of CONFIRMED

These statuses can be used to create subsequent workflows on the back of them, just like continuing different workflows based on payment status Authorized or Declined.

If the “Create shipping label” action fails, then you can assume that the shipping label was not created, because the action did not do its assigned job.

If the “Create shipping label” action successfully completes its task, then the third-party App responds with a created shipment, where the shipment object can have its own status.

The third-party can now avail shipping updates via a trigger. You can create workflows based upon these updates, like sending a confirmation to your customer when items have been shipped.

Avoid infinite loops

Certain combinations of Triggers & Actions can lead to an infinite loop of workflows being triggered. This must be avoided when building a workflow.

If you combine the Zendesk trigger "Ticket created" with the Zendesk action "Create ticket", that would result in an infinite loop:

We recommend setting up the Trigger accordingly, or putting Conditions in place to prevent an infinite loop.

Creating test routes

The Conditions Utility allows you to reference any data point from a previous block, such as the Output of a Trigger or an Action.

During your integration you might want to create different routes to get familiar with branching logic. You could create different routes based on amount, currency, down to the individual e-mail address. This capability also allows you to create very specific test routes:

Start automating

• Now that you know the best practices, why not put the concepts to a test and start building workflows?
• In case your new workflows do not work as intended, check our monitor workflows guide to troubleshoot your workflows