Ability to tie custom field editing permissions to Bundle editors only

English Forum Product Feedback
1

There is a risk to how Custom Fields are set up now.

We have had an incident last month just like described here: Asana changed one of our custom fields - huge negative impact on our company!

Someone deleted values of one of our custom library fields, which led to quite a ruckus. Hundreds of projects and views affected.

We eventually locked down the custom fields for editing, but that just locks it to one person, and as I understand it an Admin is required to unlock this field if the one locking it has left the company.

:dart:My desired outcome is that we can collaborate on custom fields settings without opening it up to the entire company.

  • Less chasing when something needs to change
  • Less hassle when someone leaves the company
  • Whilst eliminating the risk of someone throwing a monkey wrench in the operation

Possible solutions in order of preference:

2

Hi @Jan-Rienk , agree on some of your points. Editing a field needs certain company-wide education, especially to pay attention to the yellow banner along the top of the edit field modal:

image
image1236×98 8.32 KB

A low-cost solution is to select a key group of Asana members who will be the ‘gate-keepers’ of your organization’s custom fields and make them all Asana Admins, leaving one or two people as Super Admins for security settings etc.

Thus this ‘team’ of Admins could all have the power to override and edit any custom field in the library that is locked by anyone (including other admins). This is more or less the desired outcome you describe, right?

1 Like
3

I work at a multinational with thousands of users. There are just too many users to catch this with education. Right now I feel I need to take a defensive stance.

To become an admin I’d have to convince global IT to make me a team admin. I’m not sure if that’s in the cards, but I can try.

Still, I feel like I shouldn’t have to be an Asana admin to make this fool-proof in a couple of clicks.

1 Like
4

Some larger orgs make a new Asana user with a role name like Marketing Admin and it’s under that user that custom fields, rules, etc. are created.

It uses a seat, is a little extra effort, but can address many issues and doesn’t require overall Asana Admin or Asana Super Admin involvement.

Thanks,

Larry

2 Likes
5

I appreciate your help in finding a workaround, but this still feels like a hassle.

6

@Jan-Rienk,

I hear you.

Workarounds, like @Richard_Sather and I provided here, are never meant to negate the original Product Feedback request, which, by definition, will be the most desirable solution…but with one key shortcoming compared to the workarounds: it doesn’t exist! :slight_smile:

I added my workaround here for the many who will find this thread in the future and may find the approach helpful specifically for this need or generally as some treat it as a best practice. I also posted as an alternative for you to Richard’s workaround which required Admin permission which you indicated could be a hardship for you.

Thanks,

Larry

2 Likes
7

@Emily_Roman Awesome to see that this is now considered!

I’ve edited the post to reflect the suggestion that was already implemented. :slight_smile:

1 Like
8

@Jan-Rienk thank you for your thinking on this and the contributions of @lpb and @Richard_Sather . After spending more time with the Bundles, I think your suggestion for controlling access via the Bundles for fields in a Bundle is a great one, this may not make others who are not on the Enterprise version happy but the more permissions can be built around Bundles would be great for the product and teams as trying to keep track of all custom fields in an organisation (even a small one like ours) is an unnecessary overhead. Voted!

3 Likes