Why do APIs/webhooks run before Pipelines?
I'm doing some testing on an app and noticed functionality based on APIs/webhooks was completing its task well before the pipeline was triggered. The pipeline trigger was a field on a form, so when I ...
Forum Discussion
Hi Daniel,
You're dealing with concurrency. You can do this by setting the filter for the Webhook to be set by the Pipeline.
1. add a checkbox field (we name ours with "Trigger" in the name and then comment which recipe it triggers).
2. The last step in the Pipeline is to update the Trigger field for the record.
3. The filter in the Webhook is set to run when the Trigger field changes from false to true.
additional options:
make a scheduled process go through and un-check the trigger.
Form rules to un-check a trigger that is checked are also good, in cases where the Users are doing something before the check box is reset.
Make another Pipeline that runs after the Webhook when the trigger check box is false.
Problems:
One record is fine for one change.
Grid Edit, import from csv, more than one record you have to play with using %repeat on% in the Webhook.
Philosophically the Webhook is the last "Step" in the Pipeline. A lot of testing and planning are recommended in order to understand the results before deploying or the potential for making data salad is exponential.
Good luck, interested to know your results.
Jim Harrison
Portland, OR
------------------------------
Jim Harrison
transparency = knowledge + understanding : The Scrum Dudes
------------------------------
You're dealing with concurrency. You can do this by setting the filter for the Webhook to be set by the Pipeline.
1. add a checkbox field (we name ours with "Trigger" in the name and then comment which recipe it triggers).
2. The last step in the Pipeline is to update the Trigger field for the record.
3. The filter in the Webhook is set to run when the Trigger field changes from false to true.
additional options:
make a scheduled process go through and un-check the trigger.
Form rules to un-check a trigger that is checked are also good, in cases where the Users are doing something before the check box is reset.
Make another Pipeline that runs after the Webhook when the trigger check box is false.
Problems:
One record is fine for one change.
Grid Edit, import from csv, more than one record you have to play with using %repeat on% in the Webhook.
Philosophically the Webhook is the last "Step" in the Pipeline. A lot of testing and planning are recommended in order to understand the results before deploying or the potential for making data salad is exponential.
Good luck, interested to know your results.
Jim Harrison
Portland, OR
------------------------------
Jim Harrison
transparency = knowledge + understanding : The Scrum Dudes
------------------------------
Thanks for the reply Jim.
For the full story, there are three buttons that change what we call the Contact Status field that track outreach attempts. Users click the button, and the contact field either changes from what it was to what the button represents, or the contact status stays the same. Either way the button sends data to other fields that have log changes on so we can see all recent outreach attempts. Changes to those fields trigger a webhook. The problem is that some users don't use those buttons and instead change the field manually from the form. So, in order to capture that data in the activity log, I'm setting up a pipeline to fill in the same fields as the button would.
So, what we've decided to do is create the checkbox field and have the button toggle that field to yes. The webhook then runs normally like it does today and the activity is logged. I also added the checkbox field equal to checked as a condition for the webhook. Then there's a pipeline that just toggles that checkbox to unchecked so users can log similar outreach types consecutively. THEN, to cover the case when a user manually changes the Contact Status field from the form to an option we want to track, another pipeline runs and part of the trigger is that the checkbox field is unchecked.
I asked the original question because, if the Pipeline to toggle the checkbox field ran before the webhook, then the webhook wouldn't run based on the added condition. Why add that condition to the webhook? Because the field that displays the activity log is based off the fields the button captures that trigger the webhook. So, if the pipeline to capture the manual change runs without an added condition, it would also trigger the webhook and log the same activity twice.
------------------------------
Daniel Johnson
------------------------------
For the full story, there are three buttons that change what we call the Contact Status field that track outreach attempts. Users click the button, and the contact field either changes from what it was to what the button represents, or the contact status stays the same. Either way the button sends data to other fields that have log changes on so we can see all recent outreach attempts. Changes to those fields trigger a webhook. The problem is that some users don't use those buttons and instead change the field manually from the form. So, in order to capture that data in the activity log, I'm setting up a pipeline to fill in the same fields as the button would.
So, what we've decided to do is create the checkbox field and have the button toggle that field to yes. The webhook then runs normally like it does today and the activity is logged. I also added the checkbox field equal to checked as a condition for the webhook. Then there's a pipeline that just toggles that checkbox to unchecked so users can log similar outreach types consecutively. THEN, to cover the case when a user manually changes the Contact Status field from the form to an option we want to track, another pipeline runs and part of the trigger is that the checkbox field is unchecked.
I asked the original question because, if the Pipeline to toggle the checkbox field ran before the webhook, then the webhook wouldn't run based on the added condition. Why add that condition to the webhook? Because the field that displays the activity log is based off the fields the button captures that trigger the webhook. So, if the pipeline to capture the manual change runs without an added condition, it would also trigger the webhook and log the same activity twice.
------------------------------
Daniel Johnson
------------------------------
- Hi Daniel,
Thanks for the description.
It sounds like you're dealing with governance problems in terms of giving Users two routes. I recommend removing one route if possible "you get the button or the DDL but not both" OR you can separate your routes using forms. Create separate forms for each route and then depending on the route the user takes display one form or the other. You can also control when a field is editable or visible with the form properties.
For example we make two or three fields sometimes, one for data from a master data source, one for data entry from the end User and one formula field that merges the other two for display. This allows you to display the User data entry field in add record mode, and the merge field for edit and view mode. The master data field is ultimately the control field written to by a controlling data source. The data entry field allows the Users to get work done without being gated by the other fields.
Also it sounds like there is a missing logic step in that last paragraph hasn't been handled. Maybe break that apart into steps and look at the logic there to see if there is something missing.
Good luck,
Jim Harrison
Portland, OR
------------------------------
Jim Harrison
transparency = knowledge + understanding : The Scrum Dudes
------------------------------- Hey Jim,
I don't think I can remove one route because the button route allows user to log consecutive contact attempts. There's now way with a multi-choice field to change from Email to Email, for example. With the button, the user can click email, let a few days go by, and click email again, thus logging both activities. And I can't get rid of the multi-choice field because there are only 3-4 contact attempts we want to log activity for, but 21 other choices like Out of Office, Declined, In Dialogue, the list goes on.
------------------------------
Daniel Johnson
------------------------------- Just came across this post and I think it highlights a challenge with pipelines. As designers/developers we would like to have tools that work in the 'back end' of applications, responding to user actions, updating data and showing the results back to the user (well, I would). Automations worked quickly enough for this to be possible most of the time, but pipelines don't and we either have to implement workarounds or convince users that their actions are being reflected in the data, despite what they see on the screen.
------------------------------
Jeremy Anson
------------------------------
