How do I get a request to behave correctly across multiple projects?

[Jose_Mejia1]

I am trying to multi-home a parent level task to two different projects and when I try to adjust the request status it moves it to the proper section of one project but not the other and vice versa. You’ll see from the screen captures (issue1.png) that even though the tasks are labeled as “New” they are not migrating to the “new” section of this particular project. However when I select them to “convert to” it shows me two different “request” (issue2.png) options and after I select “the other request option” it then places it in the correct section of the project I’m in (issue3.png) but when I visit the other project that It’s multi-homed into - it places it in the No Value Section. (issue4.png)

[Phil_Seeman]

Hi @Jose_Mejia1,

This is a function of the IMO unfortunate way that Asana has implemented custom task types, and a perfect example of why it’s an unfortunate implementation.

The issue is that custom task types are strictly project-based; that is, a custom type is only defined locally to one particular project. HOWEVER, if a task with a custom type is multi-homed to a second project, its custom type comes along with it in that other project - but only for that task, not the custom type definition itself.

So in your case, what I’m sure you’ve done is create a custom task type in each of those projects which happens to have the same name and status options in both projects - but to Asana, they are two completely different and unrelated custom types. That’s why in your Issue2 pic you see two “Request” custom types.

Clear as mud?

I’m going to do some playing around and see if I can figure out some type of workaround for your (very valid) use case. To do so, can you say more about how you’re expecting the section moves to occur? I’m assuming it’s via rule(s), so if you could provide screenshot(s) of the rule definition(s), that would be great.

Of course now that you have the above explanation, you’ll probably be playing around, too, so let us know if you come up with anything workable!

[Jose_Mejia1]

Thanks so much for this thoughtful reply. That makes a lot of sense. What you’re suggesting makes absolute sense. I know how to do that so I’ll give it a try and report back to you if it works. All the best!

[amy598cross]

@Jose_Mejia1

I am trying to multi-home a parent level task to two different projects and when I try to adjust the request status it moves it to the proper section of one project but not the other and vice versa. You’ll see from the screen captures (issue1.png) that even though the tasks are labeled as “New” they are not migrating to the “new” section of this particular project. However when I select them to “convert to” it shows me two different “request” (issue2.png) options and after I select “the other request option” it then places it in the correct section of the project I’m in (issue3.png) but when I visit the other project that It’s multi-homed into - it places it in the No Value Section. (issue4.png)

Hello @Jose_Mejia1,
This behavior suggests that each project has its own request type mapping, and multi-homed tasks don’t sync status across differing workflows. When converting, you’re likely selecting a request type valid for one project but not recognized by the other—hence the “No Value” placement. To fix this, ensure both projects share the same request types and status mappings, or use automation rules to sync transitions across them. Let me know if you’d like help setting that up.

Best Regards,
Amy Cross

[Joanna_Czarnobilska]

Hey @Jose_Mejia1

That’s an interesting use case!
Have you tried bundles?
If you bundle your sections and rules (assuming that you run a rule that moves a task to a certain section based on custom task type), and use the bundled set in the second project - the rule will run correctly, despite not bundling the custom task template.

Please try to see if that will work for you!

[Richard_Sather]

@Jose_Mejia1 , you can achieve what you need if you forget about task types, sections and rules. All you need is a single-select field called ‘Status’ or anything else you want and add it to your library. Add that field in both projects and Group both projects by that field also.

When multi-homed, your taks will appear in the same sections (groups) across both/all projects that have that status field and grouped by it.

[Phil_Seeman]

@Richard_Sather

All you need is a single-select field called ‘Status’ or anything else you want

True, this is a workaround for sure, but just to be clear, using a custom field is distinctly different from and loses some of the advantages and reasons for using a custom type.

@Joanna_Czarnobilska

If you bundle your sections and rules (assuming that you run a rule that moves a task to a certain section based on custom task type), and use the bundled set in the second project - the rule will run correctly, despite not bundling the custom task template.

Interesting - I hadn’t thought of trying this, and actually wouldn’t have thought it would work! @Jose_Mejia1 please do try it and report back (assuming you’re on Enterprise and have access to bundles).

[Richard_Sather]

@Phil_Seeman

using a custom field is distinctly different from and loses some of the advantages and reasons for using a custom type.

Yes for sure, totally agree and that is why, as you know, I have been advocating for custom types to be supported in Bundles, that will make this feature scalable.

Custom task types and statuses supported in a Bundle's task templates

The recently introduced Custom Task Types & Statuses are fantastic but I find them limiting with regards to universal dashboards or portfolio dashboards because each custom type is unique to a project and cannot be quantified globally. I’m hoping a fast follow will be to add support for custom task types in Bundles which would resolve these initial shortcomings.