Creating Fields overides values

Does each department/person need to create a uniquely named Status field?

Our Marketing team has been utilizing Asana several years They have a Status field with their values.

A member from another department wanted to add Status, with different values, to their project and created NEW field with the name of Status, thinking it would create a separate status field for their project.

What ended up happening is the original Status field that Marketing created was over ridden. No warning messages were given to warn the values were about to be edited and the field Status was in several projects. This create a big mess that appears to unreversable.

Hello @Lynnette_Procopio ,

That should not be happening, and I can’t replicate it in my environment. Are you 100% sure they actually created a new field instead of just editing the existing one? Do you currently see two fields with identical names in your field library?


No, She deleted her custom field with the identical name. When I asked her if she check the global library first to ensure her new field was not there, she said No. She proceeded to create the field with the identical name. It does appear a field with an identical name can be created for a different field type – for example Status as an Text field, Status as a multi-select field.

I am planning on sending out this message to staff – Thoughts?

Following a recent discussion and incident, I wanted to provide additional clarification and guidance on custom field management:

Global vs. Local Custom Fields:

  • Global custom fields are intended for organization-wide use and should be added to the field library for easy access across projects.

  • Local custom fields are project-specific and should be created only when necessary, without adding them to the field library.

  • Use these prefixes to distinguish a similar custom field, such as Status, FI-Status (finance Status)

  • FI-Finance/Accounting

  • SS-Sales/Sponsorship

  • GE-Global Events

  • PC-People/Culture

  • LP-Learning Programs

  • MK-Marketing/Communications

  • PU-Publications

Field Creation and Library Check:

  • Before creating a new custom field, always check the organization’s field library to avoid duplicates and promote consistency.
  • If a field already exists in the Global library but requires modifications, consider whether the changes will impact other projects before proceeding.

Hi @Lynnette_Procopio ,

My apologies, my last comment was misleading and I’ve edited it for clarity. You cannot have identically named global fields (regardless of type), but you can have local fields that share a name with a global field (or with other local fields on the same project).

That said, I still don’t understand how the situation you’re describing is possible, since there is no way that your colleague could have created a global field with an identical name. It’s simply not possible for one field to overwrite another (in the manner described) unless there’s a bug in the system. IMO, this is more likely human error.

I’m thinking she must have either just gone in and edited the existing field or perhaps she created a local field, then deleted the global field by accident or something of that nature and is now providing inaccurate or partially accurate information to you. You could reach out to Asana support to see if they can help you recover your old data or confirm if this is indeed a system bug.

I agree with your internal comm, and would add that you might consider locking fields so only one person (you, if you’re an admin) can edit those fields. This will prevent people from either editing or deleting important fields.


Thank you for feed back on my communication message to staff.

Appreciate your support.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.