Skip to main content

We’re building out our first Workflow using Pipefy and alongside this are using Make (an integration tool, akin to ZAPIER) to process data and keep in sync with our other systems.

All very straightforward except when it comes to the challenge of ensuring that the integration engine keeps in step with events on Pipefy.

I’ve developed a solution for this but I want to know whether anyone has a better approach. My solution is as follows;

Whenever a Card is moved, we want the Make integration engine to process data. A webhook is setup accordingly. However, we need to ensure that;

  • if the Make integration fails for whatever reason, then any further processing on Make is halted until the issue is resolved.
  • if the Webhook fails to fire (it happens!), then any processing of subsequent Phase changes on Make is halted
  • a warning message appears on the Pipefy Stage if any of the above conditions have occurred

Ignoring the warning message, then this is the solution I’ve come up with;

1. the Pipefy Pipe has a 'hidden' field on the Start Form 'hidden_process_moved_card_request_placed_for_make_on_phase_id'.
2. Whenever a Card is moved to a Phase, an on-app automation checks the value of this field and if blank, updates the field value to the ID of the current Phase, otherwise if not blank (then the on-app automation does nothing
3. a Pipefy field validation hides all fields on all Phases if the value of this field is not blank (this prevents a user changing data states whilst the Make call is outstanding)
4. A Make Scenario executes whenever a card is moved (via webhook). It first checks to see if the value of the hidden field 'hidden_process_moved_card_request_placed_for_make_on_phase_id' = current Phase ID (the latter passed in the webhook). If these values are the same, then the webhook is processed, otherwise it is abandoned.

 

Can anyone come up with a simpler solution?

Can you put a print of your flow / scenario in Make?

Hi @mark-theotcentre!
Do you still need help at this point?

This is a very nice writeup of an actual problem, thank you @mark-theotcentre 

I am not using Make anmore but my own code to interact with the API, yet the problem is the same.

In my case, I was fortunate enough to be able to restructure the workflow and the external automations such that they do not require previous webhooks to have occurred / i.e., they perform error correction where needed. In the worst case, using a similar procedure as you have but without hiding the fields, I just show the user a “Dynamic Content” field (an uneditable field) with a warning, that the state might not be current yet, and what the consequences of proceding anyway would be.

I think, these problems are therefore very dependent on your dataflow / your pipe. Can you share any details, such that we might suggest an alternative?

 

Assuming there is no way to loosen your restrictions, I do not see a simpler solution than the one you have come up with.

This is a very nice writeup of an actual problem, thank you @mark-theotcentre 

I am not using Make anmore but my own code to interact with the API, yet the problem is the same.

In my case, I was fortunate enough to be able to restructure the workflow and the external automations such that they do not require previous webhooks to have occurred / i.e., they perform error correction where needed. In the worst case, using a similar procedure as you have but without hiding the fields, I just show the user a “Dynamic Content” field (an uneditable field) with a warning, that the state might not be current yet, and what the consequences of proceding anyway would be.

I think, these problems are therefore very dependent on your dataflow / your pipe. Can you share any details, such that we might suggest an alternative?

 

Assuming there is no way to loosen your restrictions, I do not see a simpler solution than the one you have come up with.

@genietim thanks for giving this some thought.

The issues I found with the approach with dynamic fields are;

  1. A Dynamic field isn’t refreshed dynamically on screen when the API updates it.
  2. Implementation gets complex for some workflows

In the end, I decided on a half-way house;

  1. Where possible, I keep API interactions to field changes rather than phase changes and show the user time-stamped progress with the API interaction (via a long text field rather than a dynamic field) so the user can see if the API isn’t responding or something has gone wrong. It relies on them stopping at that point though! Keeps implementation simpler but it isn’t bullet proof because the user might do something they shouldn’t …

Best regards

Reply


Terms & ConditionsCookie settings