Summary
As part of the introduction of the new custom type feature (*name TBC) for tasks, we are expanding the range of available task resource_subtype values in the API. The new resource_subtype value, “custom”, will allow users to identify tasks with a custom type, providing greater flexibility in task management.
In addition to the new custom type, existing values such as “approval” and “milestone” continue to be supported, allowing for distinct categorizations of tasks based on their specific purpose or functionality.
Who is affected
Existing applications and integrations will start receiving this value for any custom types for tasks.
Why we’re making this change
This change is part of the custom types feature release for tasks, which gives users the ability to structure task objects through a defined type. By introducing the “custom” value for the resource_subtype field, consumers will be able to easily identify tasks that don’t fall into traditional categories like “approval” or “milestone”. This update provides greater flexibility in task categorization, helping users tailor task management to their unique needs.
Timeline
In the coming months, this change will be available to users with domains in Starter+ tiers. Stay tuned to this post for future updates and announcements regarding the rollout.
Usage
Developers can use the following API endpoints to view this new information:
For tasks returned by these endpoints, note that resource_subtype can soon be “custom” (in addition to the existing “approval” and “milestone” types):
{
"data": {
"name": "{{taskName}}",
"resource_subtype": "custom"
// ...
}
}
Migration steps
To take advantage of the upcoming “custom” task resource_subtype, you’ll need to add support for this new value in your task management processes. If your system plans to utilize custom types for tasks, ensure that it can recognize and process tasks with the “custom” type.
In anticipation of these changes, we recommend updating your workflows to accommodate tasks with this new subtype. If support for this new subtype is not yet planned, it’s advisable to implement a fallback mechanism. This ensures that tasks with an unknown or unsupported resource_subtype are either ignored, flagged for review, or processed according to an alternative workflow, depending on your use case.
Staying updated
We’re working on finalizing additional details and features to share as soon as they’re available. To stay informed, be sure to check back here for the latest updates!