Automations webhook are not available for non-admin users
If the users trying to trigger the "Automated Webhook" are non-admin users, they can't benefit from the feature.
All users in my account should be able to trigger an automation that includes a webhook action. (if TRIGGERED BY ANY USER is checked)
For example, this action can help them enrich data from external providers.
Right now, there is big confusion between the « create automated webhook » reserved for admin users and the availability to trigger the automation (including webhook) by all users. If everyone can trigger the automation, it shouldn’t be stopped for permission problems.
It's disappointing that only administrators can benefit from the global automated webhook functionality.
Comments
-
Hey, @AliceClovis!
You are indeed correct, as currently only users with global admin permissions can use this feature to the fullest. That said, I understand this is not ideal for your team, as you would need this maximum usage to be expanded to all users.
While we have this limitation at the moment, I will share your feedback with our internal teams so that it can be considered for future improvements. Thank you!
1 -
makes the feature extremely limited indeed. The whole point of triggering webhooks is to allow the whole team to trigger actions like invoicing, generating PDFs, sheets, etc.
Suggestion: let the "triggered by anyone" override admin settings, since this is what "anyone" implies and is a deliberate setting. Otherwise it becomes very misleading when setting up automations.
4 -
This is such a weird limitation considering it's not there for the standard Webhooks. I personally cannot think of a useful scenario that would make this useful except for bulk, one-off operations.
5 -
@Leonardo Zimmermann can you please escalate this to the team? As of now, this extremely useful update is pointless and confusing.
"Triggered by anyone" setting needs to override admin limitation, as there's usually just 1 admin in the account and a whole team of people who should be triggering the automation.
This is direly needed. Alternatively, let admins change permissions for automated webhooks.
Currently, the feature is useless.
But if it gets triggered by anyone on the team, it will solve problems that been existing in pipedrive environment forever (i.e. triggering make and zapier webhooks to get something done workflow automations can't do or pull data from another app).
2 -
HI @Leonardo Zimmermann, I agree with the other comments. Currently this unfortunately makes the long-awaited automation webhooks more or less useless. Also as mentioned before this is very confusing as "Triggered by any user" indicates that there should be no limitations for the user role, and also as mentioned this is not the case with other webhooks either.
2 -
Hi @Veli-Matti Ratinen do you mind upvoting the issue at the very top to indicate the urgency? Totally agree on all points: great update if triggered by anyone will work as expected.
2 -
Hi @Nikolai Sokolov, sure!
0 -
Hi everyone, Thank you for your cooperation. Please keep commenting and upvoting if you support this request and other feedback. Commenting and upvoting a request/feedback post will make the case much more robust with our product team.
1 -
Hi @Manuel Oliveira as pipedrive solutions partner, I cant stress enough how important it is to resolve this permission issue. Currently, the limitation makes this gamechanger feature a full show stopper.
2 -
very strange not to be able to roll out advanced functions accross all you org without taling a significant risk (of setting everyone admin). upvoted ! ( @Manuel Oliveira any news appreciated :))
2 -
It's hard to believe that it took years to finally have webhooks implemented and this is how it was designed. Without having our team members, who have permission to trigger the workflows, be able to trigger the webhook, this is essentially 100% useless and needs to be addressed as soon as possible.
4 -
Hi, everyone! I’m happy to confirm that this automation has been updated, and there is now a “triggered by anyone” condition. You can set it so any user can trigger the webhook.
4 -
@Manuel Oliveira That's awesome, thank you for the update. The only other request I have, is it possible to include the data from the objects used in the workflow in the payload, in addition to any custom variables? It would be fantastic if in the "Default Fields" there was an option to select the objects data to be included in the payload.
Due to single trigger events, lack of branching and other various limitations of the workflows, the majority of our workflows are duplicates of another with just one variable tweaked - for example 'Deal Created in Stage X' and another duplicate for 'Deal Entered Stage X', or English vs. Spanish speaker. It can be extremely tedious having to assign each and every variable for the webhook one-by-one across all the workflows.
Again, thank you for the update and for pushing for improved functionality!
0 -
Amazing news, great stuff!
0 -
Awesome!!! I am hopeful again. Thank you @Manuel Oliveira !!
0 -
Looks like it's time to update the documentation. :)
0 -
Hi @Randall Pena , thanks for that! The documentation will be updated very soon.
@wonders inside the automation, you can specify which keys and values are included in the payload and the method to be used. You can find out how it works here.
0 -
@Manuel Oliveira Sorry if I was unclear in my previous post.
The key value setup as it is, having to assign one-by-one, is EXTREMELY tedious, particularly when the workflows are as limited as they are. As I stated, we have to have multiple, nearly identical workflows, due to the limitations of Pipedrives workflows. This means we have to go in and assign the same key→values for each and every workflow. This is brutally painful.
I'm requesting that, in addition to the "custom 1:1 key→values" you can assign, all of the data from the objects used in the workflow are included in the payload by default (or at least include an option in the 'Default Fields' section of the action to include this data in the payload). So if you're using the lead object and the person object in a workflow, the webhook would send ALL of the lead and person fields WITHOUT having to go 1 by 1 and assign 50 different key→value pairs, and then have to repeat this in 4 workflows that all do the same thing.
Just like a regular webhook, when you use a 'deals' webhook, it sends all of the deal data/values in the webhook. You do not have to go assign the values one-by-one. There should be a way to include all of the object data associated with the workflow as standard data being sent in the webhook.
I hope this this makes sense.
1 -
Hi @wonders for now, it's easer just to pass the ID and then request the full info on the other end, ie fetching deal/contact/org, to get the full recordset.
0 -
having the ability to trigger webhooks in a targeted way is already such a massive improvement that I'm personally fine with doing one additional API call after the webhook receives the ID. Much, much better than the previous approach of filtering thru all of the update/create events we had to employ.
What we do now: just send the ID of the deal. Then fetch deal on the other end thru API, which contains a whole bunch of data on other objects and fetch any other object if the info in the deal isnt sufficient.
2 -
@Nikolai Sokolov I agree, it is a MASSIVE improvement to say the least.
We do a pretty good amount of data passing back and forth so it would be really nice at some point to be able to keep it as streamlined as possible and would save us a good bit on zaps. It only makes sense to me the object data would be sent with the webhook, that's how other platforms out there do it, including Pipedrive's standard webhooks.
Thanks for that suggestion though, that's definitely a great solution. I don't know why I didn't think to do that but I'm sure as hell going to! I appreciate it lol
0