Factors Affecting Existing Integrations

The Flows you create in Integry are editable and you can add different use-cases to your Flows even after publishing them. However, the changes may or may not reflect in the existing integrations. If the added use case has a potential to break a functional integration, then these changes are avoided at our end.

 

In this article, we'll list down the scenarios that may or may not have an effect on an existing integration. For simplicity we'll use an example Flow, "If a contact is created in app A, create a subscriber in app B."

 

Let's begin.

 

Let's assume, you have mapped fields, such as first name, last name, gender, etc., but not phone number.

 

 

If you map the field 'Phone' using a tag (shown above), this change will not have an impact on your existing Flow.

 

 

The next time this integration runs, this field would still be empty. Meaning, the tag is not saved for the existing integration.

 

 

Your existing Flow has 'Last Name' field of app A mapped to the 'Last Name' field of app B.

 

Let's say you change the tag for this field and map the First Name attribute to the 'Last Name' field. The next time this integration runs, the 'Last Name' field of app A would still be mapped to 'Last Name' field of app B.

 

 

Let's assume you have mapped the field 'Phone' in your current Flow. However, the trigger application does not bring contact numbers for some contacts. If you don't want to send empty values for the field 'Phone' to the action application, you can edit the action's endpoint in App Connector Builder. For example, you can add the following IF condition in the Action's Twig code.

 

By adding this condition, the attribute for the field 'Phone' will only be sent in the request if it is not empty.

 

When this integration will run, the Action's request body will no longer contain the variable for phone numbers if they're empty.

 

 

In the running example, let's say you want to update the subscriber information in app B whenever a contact is updated in app A.

 

 

To do that, you would have to add a storage step (Set Value) to your Flow and store the contact ID as a key-value pair, shown above. Next, you would also have to add a step that uses the activity Update Contact - to update the contact in app B.

 

However, when the integration runs, the additional steps won't execute.

 

 

If you want to remove an existing activity from a step in a Flow and replace it with a new one - you can do that using the Change Action option.

 

Simply go to the three dotted menu on your step and click on Change Action, shown above. You'll be asked to remove the selected Activity and replace it with a new activity.

 

When the integration will run, the Flow will work according to the new activity added to the step.

 

 

 

Let's say, you swap the two child steps of two conditional steps in your Flow, shown above. When the Flow will be executed, it will run according to the existing integration.

 

Let's say you are testing your integration and you find out that your Flow has a duplicate step. Your integration will not execute successfully with a duplicate step. For it to run, you would have to unpublish the flow and delete the duplicate step.

 

After saving your edits and re-publishing your Flow, the changes will be reflected in the existing integration