Skip to main content
Solved

Managing Asynchronous Communications with products like ZAPIER


mark-theotcentre
Forum|alt.badge.img

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?

Best answer by mark-theotcentre

genietim wrote:

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

View original
Did this topic help you find an answer to your question?

4 replies

Lucas Democh
Forum|alt.badge.img+15
  • Pipefy Legend
  • 396 replies
  • April 20, 2023

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


Lais Laudari

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


genietim
Forum|alt.badge.img+12
  • Pipefy Legend
  • 412 replies
  • April 24, 2023

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.


mark-theotcentre
Forum|alt.badge.img
genietim wrote:

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


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings