I’d like to request the option to pause or disable a task template in a bundle.
As context - I am regularly building new task templates within bundles, for a large number of team members across different teams (and projects) to access.
These task templates are often complex - for example, they often contain: subtasks with dependencies, multi-homing for different subtasks, descriptions for every subtask. This means that it makes more sense to build the task templates in the final bundle they’ll live in, rather than drafting them elsewhere, then manually rebuilding in the bundle once finalised.
Having the ability to pause/temporarily disable access to task template in a bundle would help with the following:
-
Removing access to an existing task template from a bundle if that particular workflow is not currently supported in the business, but will be used again in the future (i.e. we don’t want to have to delete it then rebuild it).
- In this instance, ideally we’d have the option to disable as needed, then enable when ready)
-
If we’re drafting a task template in an existing bundle, and other changes to that bundle need to be published, preventing that task template from being available within linked projects while we finish drafting/reviewing set-up with stakeholders.
- In this instance, we’d ideally be able to set the specific task template in the bundle as disabled as we prepare it for launch, then enable it once it’s ready for use.
Unfortunately my needs here can’t be addressed by splitting up the structure of our bundles further than we already have - otherwise we’d need a bundle per task template, or need to take our task template bundle offline entirely in between times, neither of which are suitable.
My current workaround is to write “
DONOTUSE“ at the start of the task template name, and the users who set up work with these templates are aware that means it’s a no-go. Another workaround that has been suggested to me is to Duplicate the bundle and maintain a “draft” version separate from the “live” bundle, then swap project connections when ready to publish changes, but this is not feasible either - and also feels clunky.