Our team would really like to be able to add 100 global/workspace custom fields to a single project. Is there any way to raise the limit of 30? We wouldn’t need them ever to be inherited by subtasks, just the same 100 on every task. Is this something difficult for the development team to change?
I can explain the use case in more detail, but the bottom line is, this would make it way easier to do process changes on our many long-running tasks, because adding/removing/modifying custom fields immediately affects all tasks, which is exactly what we would like.
The reason is probably a performance issue as well as the fact that it will clutter the screen. I do understand you need it though, but the product team decided against it (for now).
You can have more fields on tasks (I believe up to 60) by using multi-homing.
Thanks, @Bastien_Siebman. When you say they decided against it for now, do you mean you checked with them just now, or this is based on the fact that the limit exists? If you did check…how soon might this be revisited?
You’re right, the limit with multi-homing is 60, according to the docs. Aside from still not being enough for our use case, I’m worried that this workaround would create confusion for stakeholders and others on our wider team.
For what it’s worth, I don’t want more than 5-10 of these 100 custom fields to show in the list view—only in the side-pane or single-task view. So if the performance issue has to do with the list view specifically, maybe the limit could just apply to how many are visible there, and there could be a higher overall limit?
Oh, I didn’t realize with multi-homing the fields can “leak” past the privateness of one of the projects. OK, that’s helpful…but still, 100 would be preferred over 60 I hope they will reconsider. Clutter is subjective and, in our use case, much preferred to having to use 2 separate apps. Also if that’s what it were about, why can I have 100 subtasks? (For that matter, why are 100 subtasks performant, but 100 fields aren’t?) As for limited users…well, OK, but if the limitation is artificial or centered around the list view, then, like I said, this shouldn’t be too hard to solve.
One final limitation to multi-homing: It limits what you can do with Rules.
In my case I have a field in the secondary project that I want to trigger a section change in the primary project. This is currently impossible, since “add to project Y in section X” doesn’t override the section if the task is already in project Y. And removing and re-adding would mean losing all the data from the custom fields in project Y.
Thank you @Bastien_Siebman but I don’t understand either of these suggestions. I couldn’t find the word pivot at https://asana.com/guide/help/premium/custom-fields so the thing you seem to be suggesting is exactly what I’m saying doesn’t work. Custom field in project X can only change sections in project X, or “Add to project Y in section Z” which doesn’t affect the section in project Y if it’s already multi-homed in project Y.
Not sure that I exactly know what you mean by custom field based section, but it sounds like it further eats up custom fields which is the problem we’re already struggling with—not being allowed to have as many of them as we’d like. Plus if it doesn’t use actual sections it’s not good for integration with reporting, etc. that rely on that (dashboards, for example, can’t make charts based on that).
Thanks @Bastien_Siebman , glad to receive your message, and that you started with the premise, because it turns out to be inaccurate, so the solutions unfortunately aren’t applicable.
I have 2 projects only because multihoming is the only way to get > 30 custom fields. Project A has sections, project B doesn’t (because its sole purpose is adding more custom fields).
I want to add a rule to project B so that a custom field value change causes a section change in Project A.
Asana does not currently allow this.
Hence, multi-homing, as a workaround to custom field limits, is a less suitable workaround than I initially thought.
The easiest solution would be to simply increase the limit. I hope that the developers will consider this.
This seems to be expressed in the final comment on this thread: Custom Field Limitation - #8 by Danielle_Yockman Not sure why it was closed, as I agree with the feedback and find it perfectly valid. I’m not sure why advising people to shove more info into an unstructure text field (Description) is seen as the final word.
Maybe our team needs a more flexible tool than Asana, or should just make our own app/database to avoid limitations like this. Staying with Asana and having them increase the limit would certainly be preferred at this point though!
The pivot solution still works, as well as the section based field. Let me know if you want to organise a consulting session on the topic to deep dive on it and look at your specific example.
Hi everyone! I’m happy to announce that we just increased the limit per project from 30 to 100 custom fields this update was launched yesterday and is available to all Premium, Business and Enterprise customers.
