Goals gives a community a shared place to turn ideas into visible work. It is a lightweight planning layer for a space: structured enough to show what matters and who is helping, but deliberately less formal than a company project tracker.
Each goal combines two useful shapes. On the board it is a compact card that can move through the community's workflow. Open it, and it becomes a full article with the context, discussion, and supporting content needed to help someone understand the work and contribute well.
Planning Without Heavy Process
Goals is designed for communities where participation is often voluntary. A clear objective can attract the right contributor, but assigning every interested member to a task can turn enthusiasm into obligation. The workspace therefore makes work discoverable before it makes responsibility formal.
A new Goals board begins with the familiar To Do, In Progress, and Done flow. This shared starting point makes boards easy to recognize across spaces. As a community develops its own habits, its goal managers can adapt the columns while keeping each one connected to one of those three broader stages.
This balance matters. The board can express a real working process, including extra selection or review stages, without forcing the community into detailed schedules, long dependency plans, or a separate planning system. The result is a practical view of what the community hopes to achieve now and what may come next.
The Goals workspace keeps activity context, workflow stages, and current objectives visible in one planning surface.
One Workspace, Two Time Horizons
The board and backlog serve different planning decisions. The board is for active, visible work. Its columns show where each current goal sits in the workflow and preserve the order chosen by the people coordinating it. The backlog is for work worth keeping but not yet ready to occupy the board.
A goal can move between these two surfaces without losing its article, reference, responsibility, color tag, or prepared status. That makes the backlog more than a collection of rough notes: it is an ordered reserve of developed goals that can return to active work when the timing is right.
The workspace also provides a few ways to find the part of the plan that matters:
Search and filters deliberately pause ordering actions because the visible cards are only part of the full plan. See Board and Workflow for the board model and The Goals Backlog for the quieter side of planning.
Keep Work Close To Its Community Context
Goals can be viewed at the space, subspace, or activity level. A small community can begin with a broad space-level board. As its work grows, placing goals in subspaces and activities keeps each plan close to the conversations, documents, events, and meetings that support it.
An activity is often the clearest home for developed work because it already gathers the people and material around a shared subject. On a wider board, the activity label keeps that context visible. A permitted reporter or goal manager can also move a goal when its proper home changes.
Area placement is a visibility boundary as well as an organizing choice. Members can only browse a board, backlog, completed history, search result, or goal detail when they have access to its space area. Existing goals in an archived activity remain available to eligible readers, but new goals cannot be created there.
For practical guidance on placement, responsibility, tags, search, and filters, continue with Organizing Goals.
More Than A Card
A short title helps people scan a board, but meaningful community work usually needs more explanation. Every goal is backed by an article where the reporter can explain the desired result, add background, develop the idea, and keep relevant discussion with the work.
Selecting a card or backlog row opens that article beside the planning surface. The board position, filters, search, and backlog state stay in place, so a reader can inspect the details without losing their orientation. The goal header keeps its workflow identity close to the article by showing the current reference, area, status, assignee, and reporter. A reader can continue into the full article when more room is useful, then return to the owning board.
Opening a goal keeps its workflow identity and article together while the owning board remains in view.
Because the detail is an article, a goal can carry more than workflow fields. Where access permits, members can comment, react, give an Award as quick item-level appreciation, or save the goal to View Later. A goal can also show related participation and content signals on its card. These social cues help planning stay connected to community activity instead of becoming a detached list of tickets.
If you are ready to shape a useful objective from the first title through its developed article, follow Create and Develop a Goal.
Responsibility With Clear Boundaries
Most members are readers until they take responsibility for a particular goal or receive broader goal-management access. This keeps the plan open enough to discover while protecting the board from accidental changes.
Responsibility can be assigned to one participating person or to a space role. Assigning a role makes its current members responsible for the goal, which is useful when work belongs to a function rather than one named person. An assigned person or role member can edit that goal's title and article, change its status, move it between the board and backlog, and delete it. That authority does not extend to the whole Goals workspace.
The main boundaries are:
This separation supports a gentle progression from interested reader, to contributor, to trusted coordinator. It also lets a community acknowledge real responsibility without implying that every member has accepted an employee-style assignment.
Completion Without Losing The Story
Moving a goal into a Done category marks it as completed while leaving it visible on the active board. When finished work begins to crowd the workflow, a space owner or goal manager can clear that Done column. Clearing is not deletion: the goals and their articles move into the read-only Done Goals history.
Members can review that history from newest to oldest, open a completed goal's article, or group loaded results by day, month, or year. Time groups show the amount completed and highlight leading participants, turning the archive into a useful record of progress rather than a graveyard of hidden cards.
Cleared goals cannot return to the active board in the current release, so clearing a Done column is a meaningful housekeeping decision. Completed Goals explains the boundary and the review options in more detail.
References That Remain Useful
Every goal receives a number within its space and can display a compact reference such as VS-42. The letter key comes from the space and helps members recognize and mention goals quickly. A space manager can review, change, or remove that key without disabling Goals; spaces without a short key use a label based on the space handle and goal number.
The visible label is convenient, but it is not the goal's underlying identity. A saved goal link continues to identify the same work if the space key changes or the goal moves. In Chat, /goal can open a picker for accessible goals, while a keyed shortcut such as /VS- can narrow the search. If two joined spaces use the same key, Visual Space asks which space you mean before choosing the goal.
When a shared goal is deleted or no longer available to the reader, its reference becomes the non-clickable label Goal unavailable. This protects the inaccessible goal's former title and location. See Goal References for keys, labels, and the Chat picker.
Common Questions
Is a goal just a task card?
No. The card is the planning summary; the linked article holds the explanation and discussion that help people understand the objective and contribute.
When should a goal stay in the backlog?
Keep it there when the idea is worth retaining but is not part of the active workflow yet. Its context and planning fields remain intact until it is ready for the board.
Who can create a goal?
A signed-in space owner or person with goal-management access can create one when they also have coordinator access. New goals created from the board or backlog are published immediately, so the title and placement should be ready for other members to see.
Does assignment make someone a board manager?
No. It grants editing and movement rights for that goal only. Workflow design, assignment, tags, and area placement remain controlled by the reporter or people with the relevant management access.
Can everyone in a space see every goal?
No. Goals follow the access rules of their space, subspace, or activity. Membership in a private area is required to see work scoped there.
What is the difference between Done and Done Goals history?
A goal in a Done-category column is still on the active board. It enters the read-only history only after a manager clears that column, and it cannot be restored to the active board in the current release.
Will changing a space key break references?
No. The displayed label may change, but saved references continue to resolve the same goal. If the reader loses access, the reference safely changes to Goal unavailable instead.