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,
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
------------------------------
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
------------------------------
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
------------------------------
