Subtasks automatically inherit their parent task’s custom fields, so you should be able to read and update those custom field values through both the API and the Asana UI without explicitly adding the subtask to the project.
The main limitation in this scenario is with webhooks. Since subtasks are not actually members of the parent project (they simply inherit context from their parent task), new subtasks won’t trigger webhooks that are subscribed to the project.
There are a few ways to work around this, depending on your workflow. For example, if you’re creating subtasks via the API, you could temporarily add them to a separate project that your webhook is subscribed to. You can think of this project as a processing queue, once the webhook is triggered and your integration has processed the event, you can remove the subtask from that project via the API. This allows you to receive webhook events while keeping your primary workflow unchanged.
I’ve marked @Dominik_Brdak’s great answer as the Solution, but wanted to offer another alternative in case you wanted to avoid the additional project required.
A common workaround for years has been to have a section in the project, kept collapsed, present at the very bottom after all other sections, and called something like “Hidden Subtasks” or some other less scary name. Then you “home” the subtasks into the project and into this particular collapsed section, thereby workaround around (mostly) the side effect of the task appearing in the main tasks list. If you see this as the lesser of two evils, great, otherwise, ignore.
I concur 100%; I’ve been using subtask detection in our Flowsana integration for many years and it reliably sends webhook events on subtasks in a project that has a project-level webhook on it.
