🔐 Be careful with sensitive information in custom fields

A few months ago, I learned that there is a small “gap” in #asana’s security regarding custom fields: if someone can see a task, they can see all its custom fields, even if originating from a project they don’t have the rights to see!

Today, I learned that the situation is actually a bit more “secure”: users will only see values for custom fields within the library of the organization, and not custom fields restrained at the project level. So if you want to store sensitive information, make sure to not include the field in the organization library.

Be careful!


Great tip, @Bastien_Siebman. That’s precisely the question we should be asking ourselves when building custom fields. "Is this something someone else could use throughout the organization or data that I feel would be impactful in other projects? Typically, the answer to that question also addresses the sensitive of the information. Data that is helpful elsewhere, and to others, is likely to be public knowledge.

That said, perhaps not save to the organization library by default if you are unsure. Why? Because it is incredibly simply to go back to any previously built custom field and enable it to appear within the organization library. This isn’t a single pass decision like identifying what type of custom field to use (text, dropdown, etc)

Update: As pointed out in later posts, you do lose the ability to search across custom fields if they are project-specific. So again, it is important to know how sensitive the information is that you will be placing within custom fields!

However, you’ll immediately lose the possibility to search for that field :wink:

I’m afraid I disagree with:

The common use case is: I have sensitive data in a task so I’ll make sure that task is not visible to those who shouldn’t see any of its sensitive data, and I’ll freely use global custom fields where I 1) expect to use the custom field in more than one project, and/or 2) I want to be able to use the advanced search feature to find it.

The problem you’re warning against is rare and usually addressed as above; just don’t allow access to the task, rather than throwing the baby out with the bathwater (Bastien, I hope you know that expression or else it will appear quite odd to you unless it’s found in French too!)

Recognize that multi-homing will share the task as a whole, including all but local project custom fields.

Of course, if the custom field definition itself has sensitive captions or values, you’d never want to make that a global custom field.

I also disagree with:

While it’s true it’s easy to convert the custom field itself from a single-project-only custom field to a global one, not anticipating and putting it on the org-wide library of global custom fields hides its existence and leads against reuse and toward multiple similar custom fields. And the instantiation of those fields in projects (as opposed to the field itself) are not convertible. You must go through the tedious steps, in each project, of adding the new global custom field, showing All tasks (not just completed ones), sorting by local custom field, batch-selecting groups of 50 tasks, replicating the value of the local custom field in the new global custom field, then removing the local custom field.

Hoping I might have persuaded both of you,


With @Julien_RENAUD we have seen cases of clients who, for example, store the time it took to do the task in a field, but they don’t want the client to see it. Working your way around this could be cumbersome :confused:

What I get from the discussion is that there no idea situation, and benefit/losses for all of them!

Very interesting debate.

My opinion is that the operation should be the most logical one for people who are not Asana experts:

  • if I don’t add a field to a project then it shouldn’t appear in the tasks.
  • if I want to see it in the tasks without creating a column then I add it to the project and hide it
  • if I want to see it then I add it

Logic may be subjective, but I find it the most intuitive, but this is not the current situation.

I didn’t consider this. You mean you lose the ability to search for it when creating a Custom Field? I assume you can still use the Advanced Search to locate any Custom Fields that are project specific? :thinking:

No sir, only works with custom fields from the library.


@lpb I completely see your point and holistically agree. I don’t think there is a need to persuade as there is to clarify. When I said the following…

… I’m simply insinuating that it is important to be mindful of how you are using custom fields with a high level of confidence in how public the information should be. While it is easy to convert a field, it is certainly more difficult to consolidate any redundant global fields… as you pointed out.

I’m suggesting to not make stuff global if the information is potentially private. Rarely would I expect a custom field would have to be made global if the intent is understood upfront. However, when necessary, so be it. It’s a risk vs reward scenario, IMO

… well I’ll be… learn something new everyday :wink:

1 Like

Which one of us will summarize in a Leader Tip post “Public or private custom fields”? :stuck_out_tongue:


I tried to summarize in my post above, but it’s pretty hard to convey. For example, I really didn’t understand @Julien_RENAUD’s most recent post above?! And I don’t know if mind was fully understood based on the subsequent posts. Maybe Forum is not the ideal place for such nuanced takes?



Hi everyone,

@Marie for info the conversation we have here is similar as this one:

I totally agree with you that making a custom field local is the best way to lead to duplicates, so that’s an issue.

Nevertheless, I still think the behavior is not intuitive.

For instance, you have 2 projects: Project #1 and Project #2
If I multi-home a task then:

  • In Project #1: I have 2 custom fields: 1 Global + 1 Local
    I have chosen to have them, so I see them :+1:

  • In project #2, I don’t add those custom fields (as you can see on the “customize” panel) because I don’t need them. But despite everything I find the values of the fields in the task

So finally, even without talking about security, I find it illogical.
So if in the end it would only display what you want to display in a given project, then it would also solve the security problem.

I hope this makes my feeling more understandable :wink:

1 Like

@Julien_RENAUD I’ve always seen the custom fields you show as columns from List or Board to be a different consideration from what is represented in the tasks. A couple questions to make sure I am understanding this correctly.

  • Guests can enable any custom fields that aren’t show on a project, correct? They just can’t edit the criteria. If that is the case, it doesn’t really solve the security issue, right?
  • Are you suggesting that you disable (from the “customize” panel) projects that you don’t need? Why have them on the project then? As stated before, I’ve always looked at what is shown on the project level different from what is shown in the task. To keep the project view clean, I don’t always show all custom fields they they still might be necessary for the project.

Personally, I live that the customize field doesn’t control what is shown from both the project view and the task view. I will say, I would prefer that from the task view, all the custom fields that are mapped through multi-homing exist within a clickable link to “show more” rather than showing an extensive list by default.

@Julien_RENAUD, I appreciate the clarification. But you’re now asking for feature changes whereas the thread had previously been debating how best to use the app (as it operates now). I think it would be better to discuss that elsewhere. You’re also calling for eliminating what @Bastien_Siebman has called “cherry-picking” custom fields; I’d be against that!


1 Like

I was surprised to see this being called a “gap” in security, and I feel that’s unfair on Asana. To me, it’s just how Asana works, and makes sense. Custom field details are part of the task information, so if a user chooses to share the task with someone new (eg by multi-homing the task to a project the new person can see), it makes sense for the new person to see the custom fields as well. It would seem to make less sense to restrict this by default, because the new person may not have the information they need to deal with the task. If people want more control than what Asana currently offers concerning who can see what, it could be achieved with more detailed sharing permission settings rather than changing the default way custom fields are displayed.

1 Like

It does make sense when you put it that way indeed.

Another interesting tidbit I learned in this process too — forms are totally public links. We used to have a form with a custom field dropdown list of “future campaigns” for requesting briefs. Well, that form link is public so literally anyone could see it!

We’ve since amended that form to remove the custom field. But we did suggest to the Asana team that restricting forms to logged-in users (and then capturing the user data) would be beneficial for a number of reasons!

1 Like

Indeed, there is a dedicated thread in the forum about it.