Introducing role-based access control with custom roles!

[Emily_Roman]

Hi Asana Community!

We’re excited to introduce Role-Based Access Control with Custom Roles, a powerful new way to manage access and permissions across your organization!

This update brings:

• Centralized control: Manage organization-level permissions from the admin console
• Enhanced security and compliance: Meet security and compliance requirements with granular control over role permissions
• Standardized workflows: Create standardized ways of working across your organization by defining appropriate access levels by role
• Reduced administrative burden: Delegate user management to specified admin users and simplify admin workflows by integrating with a supported IDP for automated role assignment

Learn more in our Help Center article:

• Role-based access control with custom roles
• Understanding user role permissions

We’d love to hear your thoughts and feedback! What custom roles are you planning to create in your organization?

• Team Lead
• Contractor
• Department Director
• Intern
• Consultant
• IT Support Lead
• Other

Drop your questions or comments below, we’re excited to see how this helps streamline your access management!

Available to organizations on Enterprise+ (or via the Permissions Management Add-on).

[Bastien_Siebman]

If you’ll allow me, I’d like to share those two screenshots that I think will get people more excited than the ones you shared above.

Looks like we can indeed create completely new roles with new names and then give them specific permissions. Very exciting.

[Jan-Rienk]

@Emily_Roman Great update!

I wonder, can I assume that disabling “Create and edit AI Automations” for a user-role will only apply to AI Studio Basic and Plus? And that a user being added to the Pro builder list will override this setting?

[Jacob_Sappington]

This feeeels so closed to role based rules

[Elizabeth60]

When are these updates set to roll out?

[Virginia_Mowery]

This is incredibly exciting, and I can’t wait for the rollout and to develop this for our org. I’ve experienced the chaos of not having tight enough controls on who can do what in Asana, and I am delighted with the idea of locking this down.

[Jess_Rains]

Thank you for these screenshots–at first I was wondering what was different just based on the announcement. Now, I’ll move this up the priority list to investigate for our needs sooner rather than later.

[Tom_Bolton]

Could this be related to the fact that some of our team members are unable to access a project in list view on desktops?? Asana has been very slow to respond and fix this issue.

[Robert_Graves]

We have been using RBAC for a few weeks now (early adopter) and we love it.. but I really hope to see a LOT more functions added to this list of potential restrictions:

Ability to Add Tasks
Ability to Add Subtasks
Ability to Set Due Dates
Ability to Set Start Dates
Ability to Create Projects
Ability to Add to Projects
Ability to remove from Projects
Ability to add dependencies
Ability to remove dependencies
Ability to Select Custom Fields
Ability to Convert a Task
I could go on and on…

We know the groundwork is already laid for this since we have things like “View Only” and “Comment Only” Roles… So why not expand this ability to restrict access to all Asana features into RBAC so we can pick and choose what each new Role should be able to do?

[Jan-Rienk]

Hi @Robert_Graves,

Doesn’t every restriction on that list reduce the value of an Asana license?

Isn’t that the functionality you need to use Asana well?

I’d probably be ok with it if these could only be applied to guest licenses. But I can’t make sense of why you’d want to apply these to paid seats.

[Robert_Graves]

@Jan-Rienk I agree for “vanilla” Asana (out-of-the-box). A User should be able to do all of those things.

In our Enterprise environment, we are building extremely automated systems. Projects where the Rules and workflows dictate how a task gets from one “phase” to the next and what happens in each of those phases are very strict and controlled. The more abilities the user has to manipulate the task and subtasks on these projects, the more chances they have to “break” the workflow and stop the automation.

If RBAC were more robust, we could even allow them to retain all of the abilities that make the seat valuable to them on their own personal projects… and perhaps there could be a way to mix RBAC and project permissions so that we could lock users out of performing these changes on specific projects where we want to use these complex automations.

[Jan-Rienk]

That clarifies, thank you.

If we’d be able to apply this in a bundle-like way (strictly defined sub-set of projects) I’d be for it.

[Paula_Remez_Grid]

Hi. I think is related to this new feature. Project’s members that have a domain e-mail different from the org domain,. are not allowed to access pojects they have accesed until yesterday.

Now, they are asking access to the projects, access is granted… but still they can’t access the projects. It’s annoying…

[Jan-Rienk]

@Paula_Remez_Grid Besides mentioning it here, I’d advise to contact support for this. See: How to contact our Support Team 📧

[Paula_Remez_Grid]

Thanks Jan-Rienk! I’ve contacted support team.

I’ve found this new topic, where another organization is also having the same problem we are having in my organization:

My access is approved, but I still don't have access

I had access to a project for years. Last night it said I need to request access. My access has been approved, but I still don’t have it. It seems like I’m stuck in a loop. Access is approved, but when I try to access the project, it says I need to request permission. I tried different browsers, cleared my cookies, and restarted my device, but it still doesn’t work. Does anyone know what could be causing this?

[Steve53]

I have the same issue.