At the moment, workflow permissions aren't as nuanced as email permissions. Users with edit permissions for workflow can edit live processes while permissions for marketing emails, for example, differentiate between suggesting changes (edit) and publishing changes (publish).
It would be great to have the same permissions / distinction for workflows.
Context
After onboarding new users to HubSpot and explaining workflows to them, they are usually hesitant as workflows can do a lot of damage. If they knew that they can only suggest but not publish changes, they would feel more comfortable working with the tool.
Similarly, for HubSpot admins it would be good to know that they can provide access to the workflow tool without having to fear for potential catastrophes.
Especially in large companies with many regional teams and varying degrees of confidence and competence, it's challenging for HubSpot admins to provide quality assurance for workflows. If they take away workflow edit permissions, they become a bottleneck. If they grant workflow edit permissions, they are constantly at the edge of their seat, fearing that something could go wrong. Things that can go wrong will go wrong.
What happens if we don't get this feature?
HubSpot admins will always be a bottleneck.
General adoption of HubSpot in the company is slowed down as HubSpot admins have to work around the risks or downsides of not having these permissions.
This idea is somewhat related to these two ideas but they don't quite address the same point:
Granular Workflow Permissions – the write permissions mentioned here come close but are specifically referring to workflows that are turned off. Similar to marketing emails, users should be able to make changes but not publish them.
Edit workflows in draft mode – this idea does not go far enough in my opinion, it's missing the permissions aspect.
We need this. We had an errant workflow send out an email to our entire global database. Now users are afraid to use workflows.
I've put a manual review process in place but it's not truly enforceable without this level of workflow permissions.
There should also be a way of limiting the risk exposure of workflows. Perhaps workflows could be truly partitioned by team, similar to lists. If a member of team X creates a workflow, then the trigger criteria has a filter added by default of "results limited to team: X"?
I would echo that, and generally like to see a "draft" permission level across HubSpot assets.
Things like lists, forms, marketing emails would benefit from users being able to have access to them but depending on the size of (and process in) an organisation having a draft option allows for approval and quality control.
We have 21 active workflows currently running as we automate our business. We have more planned to come as well. As our business grows, we are finding ways to improve and expand our current workflows.
Right now, I have 12 workflows that I want to expand and add more actions to. I don't want to make my changes live yet, and I definitely do not want to edit the live ones. My only option is to clone each one right now, which can get out of hand quickly. Having a draft to make live will make things so much easier.
The way Method CRM does it is super smart, where you can create a Draft version of your live worklfow. Any automated process happens on the live version only. Admins or other customizers can test the draft before publishing it to be live. Once you are done with your changes, you make the draft live and it replaces the current live workflow. If for any reason something wrong goes on, you can revert back to the older version. But the whole idea is that you copy the live version within the workflow itself (you're not creating a totally new workflow). This makes it a lot more manageable and can track history easily.
We definitely need this as well - to still allow certain users to continue to create/modify workflows AND ensure they are not published without a senior level review / approval. Too many times we have found data integrity issues and then uncover a workflow as the "culprit", and most times, the workflow was created by someone who was not aware of our guidelines or how the data is integral across the entire CRM.
We absolutely need this for our company. It's so easy for a very well trained team member to make a change to a workflow that causes chaos, let alone a brand new person. It would be ideal to be able to review changes that are made by team members, even for a second set of eyes before something runs.
Approvals shouldn’t be limited to CMS material only ! We have numerous sensitive processes that require revision before they’re allowed to operate unsupervised. Indeed, these processes can operate somewhat safely based on their pre-configured conditions, as outlined in the workflow configurations, before they’re initiated. However, this alone is insufficient to prevent catastrophic situations. Extensive processes need to undergo an audit before they’re activated.
We also need this. The consequences of turning on a workflow that hasn't been approved by an admin or someone who is more confident can be quite severe. It would be really good to allow people to create workflows, edit them but not publishing them/publishing changes on live workflows.
I'm currently working in a global portal with 60+ teams. Granular permission sets are really important to balance freedom, overview of owned assets only and risk mitigation.
You don't want to give every (new) user permission to change workflows and impact thousands of contacts or properties.
But more experienced users shouldn't be withold from asking colleagues with more permissions to create a simple notification or follow up mail workflow.
What I would like to suggest: differentiate permissions between workflows and simplified workflows.
Marketeers can gain the permission to create simplified workflows for internal and external notification mails. But can still be excluded from workflows that branch, set or change properties.