API Development

Override Integration Builder Flow Variables

Override Integration Builder Flow Variables

A major component of Integration Builder is Flow Templates.

Flow Templates enable you to build a single template for a flow that you can reuse with different connectors and values. After you build a flow template, you can then create a flow instance where you replace the flow variables with actual connector instances and values. This approach helps you build efficient and reusable flows.

For example, I recently worked on a manual triggered flow to share Syncplicity files with users via a share link.

The client wanted the option to enable Syncplicity Rights Management on the file share links. My first thought was to create a flow variable to hold a boolean variable, isIRMEnabled.

Then I could create two flow instances, one with isIRMEnabled set to true and another with isIRMEnabled set to false. Then they would have two flow instances that they could trigger depending on the need.

I then thought of a potentially more robust solution where I could have one flow instance and then override the isIRMEnabled variable when I trigger the flow instance by passing in the override value.

This blog post will describe how to do this easily.

Trigger The Manual Flow

First, let’s review how we trigger a manual flow via an API request.

When you create a manual triggered flow instance, you can trigger it using a POST API call to /formulas/instances/{instanceId}/executions endpoint. How would you know this? If you click on the trigger step of your manually triggered flow and click edit, you will see the full API trigger URL as shown below:

Trigger Step for Manual Trigger Flow

Besides the flow instanceId, you will also need the authorization header for your user and org. You can find this information by clicking on the gear icon in the Integration Builder interface as shown below:

Find Your Authorization Header

Finally, you need to pass in a JSON object for the body of your POST. An example curl command is shown below:

curl -X POST "https://staging.cloud-elements.com/elements/api-v2/formulas/instances/450196/executions" -H "accept: application/json" -H "Authorization: User XXXXXXXXXXXX, Organization YYYYYYYYYYYY" -H "Content-Type: application/json" -d "{\"additionalProp1\":{}}"

So, now we can use a better JSON payload and send some data, namely the isIRMEnabled value that you want to use as an override for your flow as follows:

curl -X POST "https://staging.cloud-elements.com/elements/api-v2/formulas/instances/450196/executions" -H "accept: application/json" -H "Authorization: User XXXXXXXXXXXX, Organization YYYYYYYYYYYY" -H "Content-Type: application/json" -d "{\"isIRMEnabled\":true}"

 

Use the Override Value in Your Flow

In order to leverage this value in your flow as an override, you will need to add a JS Script step to your flow before the variable is referenced. In the flow below, you can see that immediately below the trigger is a JS Script step called overrideConfig.

Example Flow

The overrideConfig JS Step contents are shown below:

if(trigger.args.hasOwnProperty("isIRMEnabled")) {
   config.isIRMEnabled = trigger.args.isIRMEnabled;
}

done({});

In the Javascript code above, you can see that we are first checking to see if the isIRMEnabled field is present in the POST body and then we are setting the instance variable to the value passed in.

The prepareGetShareLink JS Script step references the instance variable as follows:

.
.
.
let body = {}

if(config.isIRMEnabled) {

  body = {
    "ShareLinkPolicy": 4,
    "Users": [{ "EmailAddress": steps.getEmail.response.body[steps.getEmail.response.body.key][0].email}],
    "ShareType" : 1,
    "IrmRoleType" : 1,
    "IsIrmProtected" : true
  }

} else {
  body = {
    "ShareLinkPolicy": 3
  }
}
.
.
.

Summary

In this blog post, we saw how easy it is to override flow instance variables for manually triggered flows by passing in the override value in the trigger API body.

Learn how to set up a two-way SSL for Integration Builder Connector Instance.