Collections
A collection is a saved query that describes a set of work items. The query is written in CQL (Collection Query Language), and the collection updates automatically as items are created, edited, or moved.
Collections are global. They live above workspaces, not inside one, so a single collection can match items across every workspace you have access to. They are also shared, not private to the user who created them, so the whole team can rely on the same named slices of work.
Use collections to build slices that cut across workspaces, iterations, or item types. For example:
- "Open bugs assigned to me across every workspace"
- "Release candidates targeted for the next two weeks"
- "Escalations from customers on the Enterprise plan"
- "Frontend work in progress"
- "Items blocked for more than 5 days"
Any view (board, list, calendar, roadmap) can be pointed at a collection, not just at a workspace.
How collections work
A collection has three parts:
- A name and (optional) description so people understand what it represents.
- A CQL query that defines membership.
- A default view (board, list, calendar, roadmap, etc.) so opening the collection lands you in the right place.
You write the query once. From then on, the collection tracks reality. If a bug closes, it leaves the "Open bugs" collection without anyone touching the collection itself. If a new bug is filed and matches the rule, it appears immediately.
Collections vs Jira filters
If you have used Jira, collections look superficially like saved JQL filters. The mechanics are different in ways that matter:
| Jira filter | Windshift collection | |
|---|---|---|
| Definition | JQL query | CQL query |
| First-class object | No, a saved search owned by a user | Yes, a top-level object alongside workspaces and pages |
| Ownership | Owned by the user who created it | Shared, not owned by a single user |
| Powers other features | Provides the data source for boards and dashboards | Can drive any view directly: board, list, calendar, roadmap, tree |
| Default view | Always the issue navigator | You choose (board, list, calendar, roadmap, etc.) |
| Sharing | Per-filter share settings, with private filters as the default | Shared by default, no private-per-user mode |
| Scope | Site-wide; filters can reach across projects | Global; queries can reach across every workspace |
| Updates | Live, on each search | Live, continuously |
In short: in Jira, a filter is a saved search you point a board at. In Windshift, a collection is the unit of work you want to look at, and the view is just how you choose to render it.
When to use a collection
Reach for a collection when:
- You find yourself running the same filter repeatedly.
- A team or person works against a slice that spans more than one workspace, iteration, or item type.
- You want a board, list, or calendar that updates itself as items change.
- You want to share a "view of work" with a stakeholder without giving them a tour of the filter UI.
If you only need to slice a single workspace temporarily, the inline filters on the list and board are usually enough. Save it as a collection once the slice becomes recurring.
Tips
- Name the outcome, not the rule. "Release candidates this week" beats "type = Story AND fixVersion = 1.4".
- Keep queries narrow. If a collection grows beyond what fits on a screen, split it.
- Pair the collection with the right default view. A "due this week" collection makes more sense as a calendar than as a list.
- Archive or delete collections that are no longer being looked at. Stale collections are worse than no collection.