Workflow automation should be available at the company level, notthe individual level

Jean Kany
Jean Kany Posts: 17
Second Anniversary Photogenic

One BIG issue with workflow automation is that they are linked to the person that builds them.

That means that if someone else in the sales team needs to take over that workflow automation, they need to completely redo the whole workflow. 

 

I automated 18 months ago a sales pipeline that including 5 different types of emails and multiple activities. But each email was always sent from me. When I transferred this pipeline to another salesperson (who would own the deal, the person and even the organization), the emails were still sent from me. 

After checking with Pipedrive, they confirmed that the automations are connected to the user who created that automation (via the API key) and therefore, to have the email sent from another sales person would require that other person to redo the entire workflow automation by himself. He could not even ask our Pipedrive Administrator for help, since only him/her can build that automation. 

Since for this pipeline, we change Sales person about every 6 months (if not faster), that means a new sales who knows nothing about Pipedrive must build a brand-new workflow automation by himself or herself. 

 

This is highly not scalable. A workflow automation should include the sender's email, for instance, and should be transferable to other people to manage.

 

Here is the answer from Pipedrive:
You can use workflows in a complete company level, only that the emails will always be sent by the owner of the automations account.
I have checked and it is a limitation on our end for sure.

But this is the only way to send emails.

Because if they wanted they could make you trigger emails that you would not like. Let's say you and one user. They know that today you going to win a deal or create one. And they create an automation where when you win a deal you send a specific email to another person that is not related to anything in Pipedrive but it is a resignation letter for example.

This can actually be manipulated. So it is like the user entered your Gmail details logged in and triggered and email. There is no way to prove for sure that it was a mistake or not. So we preferred that and automation email can only be sent by the owner of the emails so that it is not manipulated in any way.

The explanation makes sense. However, Admin should at least be authorized to make those changes. 
This could be managed from the "Permission Set" window.

Automation is a big advantage for SMB deals, and it's a pity that Pipedrive doesn't allow companies to scale their sales operations that way.

 

Does anyone have the same issue?

Comments

  • Justus Lubahn
    Justus Lubahn Posts: 58
    edited February 2021 #2

    Not sure, if I misunderstood, but I have built multiple automations, that other users trigger and use as their own, including Emails. These Emails are sent by the person triggering the automation, not by the creator of said automation. 
    So, independent of the creator of an automation, as long as you set it to be "triggered by everyone" and not "just triggered by me" it works for everyone. And Emails are by default sent by the person triggering that automation, as long as they have their Email synced with Pipedrive.
    This way there is no issue with "manipulation" by sending Emails from another persons account either.

  • André Vidal
    André Vidal Moderator Posts: 18 PIPEDRIVE CUSTOMER SUPPORT
    10 Comments Pipedrive Employee
    edited February 2021 #3

    Hello @Jean Kany ,

    I work in the Pipedrive support team and I thought I could jump in to help. 

    All you say is true. Your description was accurate, so it seems like you understood all the limitations that we currently have with actions that involve sending emails. This only happens with automations where one of the actions is to send an email. With others, that do not involve emails, this isn't a problem. 

    As the email in Pipedrive is a private feature, the same way it isn't allowed for a user to go to another users' inbox to send an email, it is also not allowed for a user to build an automation that would send a message from another user's email. 

    I definitely understand all your points that you mention when you wrote about scaling or replacing users. Our Product Management team is usually very attentive to the posts of the community, but I will also share this with them directly. i appreciate your feedback. Hopefully this can be used to improve our current options. 

    @Justus Lubahn , I am also curious about your process. But what Jean said is true. If you have automations to send an email, when they trigger, the email is always sent from the email address the creator of the automation has synchronised with Pipedrive. Would you mind double-checking if that is the case? 

  • Jean Kany
    Jean Kany Posts: 17
    Second Anniversary Photogenic
    edited February 2021 #4

    Thanks Andre and Justus.
    Appreciate both's feedback.

  • Justus Lubahn
    Justus Lubahn Posts: 58
    edited February 25 #5

    Alright, I messed up. You guys are of course correct - it does not matter who triggers the automation or who is owner of the deal, the sender of automated mails is the creator of the automation. I also understand the "danger of manipulation argument", as a malicous person could create automations for people that are not aware of them and involuntarily send emails from their account they do not approve of - although I agree that for an admin-level account this could be considered, since the people who are admin usually are trustworthy people within the company that have other significant responsabilities aswell.

    For us the fix will be simple, since I can just log into the account of the single person that will be using these automations (or at most the two people) and create the respective automations from their account. So they will work properly, but only with me going into their account - which is one more counter-argument towards the security-argument since going into their account definitly is more invasive.

    Still, I understand where you guys are coming from and appreciate you value safety. Maybe there is some middle ground here though.

  • Jean Kany
    Jean Kany Posts: 17
    Second Anniversary Photogenic
    edited February 2021 #6

    Alright, I messed up. You guys are of course correct - it does not matter who triggers the automation or who is owner of the deal, the sender of automated mails is the creator of the automation. I also understand the "danger of manipulation argument", as a malicous person could create automations for people that are not aware of them and involuntarily send emails from their account they do not approve of - although I agree that for an admin-level account this could be considered, since the people who are admin usually are trustworthy people within the company that have other significant responsabilities aswell.

    For us the fix will be simple, since I can just log into the account of the single person that will be using these automations (or at most the two people) and create the respective automations from their account. So they will work properly, but only with me going into their account - which is one more counter-argument towards the security-argument since going into their account definitly is more invasive.

    Still, I understand where you guys are coming from and appreciate you value safety. Maybe there is some middle ground here though.

    Thanks Justus. I agree with you.

  • Deals_26239
    Deals_26239 Posts: 2
    edited February 25 #7

    The bad actor problem can easily be solved with proper permissions. By default an automation should only be triggered by yourself, and an admin is required to approve it to be used company or group wise. Further changes on the flow should also be approved by and admin. A simpler a less complex to implement solution could be that only flows created by an admin can use the email of the user that triggers the automation. Right now it's a little silly that automation emails say things like "Hi, I'm X" but the origination address is from user Y.

  • Justus Lubahn
    Justus Lubahn Posts: 58
    edited May 2021 #8
    Deals said:

    The bad actor problem can easily be solved with proper permissions. By default an automation should only be triggered by yourself, and an admin is required to approve it to be used company or group wise. Further changes on the flow should also be approved by and admin. A simpler a less complex to implement solution could be that only flows created by an admin can use the email of the user that triggers the automation. Right now it's a little silly that automation emails say things like "Hi, I'm X" but the origination address is from user Y.

    Totally agree. Bad actor problem is solvable without having to miss such important functionality!

  • Deals_26239
    Deals_26239 Posts: 2
    edited May 2021 #9
    Deals said:

    The bad actor problem can easily be solved with proper permissions. By default an automation should only be triggered by yourself, and an admin is required to approve it to be used company or group wise. Further changes on the flow should also be approved by and admin. A simpler a less complex to implement solution could be that only flows created by an admin can use the email of the user that triggers the automation. Right now it's a little silly that automation emails say things like "Hi, I'm X" but the origination address is from user Y.

    I think part of the problem may be that the automation part does not come from Pipedrive, but from an acquisition, they did last year, and integrations are always hard.