Features and ClickApps
Features and ClickApps
This domain tests the modular feature system: which capabilities exist, where they can be switched on, and what happens to data when you switch them off.
How ClickApps behave
- ClickApps are per-location toggles. They can be enabled at Workspace, Space, Folder, or List level and cascade downward until a lower level overrides them.
- Disabling a ClickApp hides its UI and behaviour; it does not delete the underlying data. Re-enable it and the entries return.
- Typical ClickApps include Custom Fields, Time Tracking, Dependencies, Milestones, Priorities, Tags, Automations, Email, Forms, Sprints, Workload, Reminders, Multiple Assignees, and Nested Subtasks.
- Custom Fields are typed: text, number, currency, date, dropdown, labels, checkbox, rating, formula, relationship, and rollup. Renaming a dropdown option keeps existing values; deleting the option clears them.
- Views and Dashboards are separate from ClickApps. Turning off a ClickApp removes its column or panel from every view in that location.
- Some settings are workspace-level only, such as custom task IDs or who may create Spaces, so do not hunt for them per List.
Worked example
A sprint team needs story points, time tracking, and a board, but no email. Enable Sprints, a number Custom Field called Points, and Time Tracking at the Space so every current and future List inherits them. Leave Email off at the Space. If one List later needs Email, enable it there as an override rather than at the Space. The reasoning: configuration as high as it applies, exceptions as low as they occur.
Traps that cost marks
- Believing a disabled ClickApp deletes data. It hides it.
- Enabling a feature on a single List when the intent was workspace-wide coverage.
- Confusing a ClickApp with a view. A Board is a view; Sprints is a ClickApp.
- Assuming every feature can be toggled at every level; some are workspace settings.
- Overriding at a List and forgetting the parent setting still governs its siblings.