Use Tree view

Tree view shows how Goals/OKRs cascade

Tree view is the map view for a Session. It lays out Objectives and Key Results so you can see how work rolls up, where supporting Objectives sit, and which Key Results belong to each Objective.

Use Tree view when you need the structure, not just a table. A list is excellent for scanning rows, editing titles, and working through many items. Tree view is better when you want to understand alignment: what supports what, which Objective is overloaded, and where a Key Result may belong somewhere else.

If you are new to the model, read Understand Goals/OKRs first.

Availability and permissions

If Tree view is visible but rearranging is not available, check whether you are in an editable Session and whether filters are limiting the visible hierarchy.

Open Tree view

Open Goals/OKRs, then open the Session you want to review. Use the view controls to switch from List to Tree.

Tree view focuses on the Objective and Key Result hierarchy inside the current Session. It is different from the Session list on the Goals/OKRs home page. The Session list can show Parent Sessions and child Sessions. Tree view shows the structure within one Session.

Move around like a map

Tree view uses canvas-style navigation. You can pan across the map, zoom in when you need detail, zoom out when you need the whole structure, and use Fit to screen to return to a readable overview.

This is useful for large Sessions. Instead of scrolling through a long table and trying to remember which Objective supports which parent, you can move around the structure visually and focus on the part of the plan you are discussing.

On smaller screens, Tree view uses more of the screen so the map has enough space. If labels feel crowded, zoom out, use Fit to screen, or switch to List for detailed row editing.

Understand the hierarchy

Tree view can show cascading Objectives. A parent Objective represents a broader direction. A child Objective supports that direction. Key Results sit under Objectives as measurable outcomes.

Use hierarchy when it explains real alignment. For example, a company Objective can have department Objectives beneath it. A launch Objective can have readiness Objectives beneath it. A customer-support Objective can have documentation, product, and operations Objectives beneath it.

Do not turn hierarchy into a task breakdown. Tasks and execution details belong inside the Initiative canvas. Key Results measure outcomes. Objectives explain direction.

Use drag-and-drop to adjust structure

Tree view supports drag-and-drop for changing hierarchy and order when the Session is editable and the current view shows enough context. Moving an Objective can change its parent, make it a sibling of another Objective, or reorder it within the same level. Moving a Key Result can reorder it or move it to another Objective.

Drag carefully. A hierarchy change affects how the Session is interpreted in List, Tree, detail views, and later reviews. After you move an item, confirm it appears under the correct parent and that the Session still tells the right strategy story.

If dragging does not work, check for active filters, search, custom sorting, or view-only access. Partial views can hide the surrounding structure needed for a safe move. Switch back to the default Session view, clear filters, and try again. Use Troubleshoot OKR permissions if the controls stay unavailable.

Use Tree view during planning

Tree view is useful after the first draft of a Session exists. Start with Objectives and Key Results in List view if that is faster, then switch to Tree view to inspect whether the structure makes sense.

During planning, look for Objectives with no Key Results, Key Results that appear under the wrong Objective, branches that are too deep to explain, and parent Objectives that are really just labels. The map makes those problems easier to spot.

Use Tree view during review

During review meetings, Tree view helps people understand why progress changed:

• If a parent Objective is at risk, inspect the child Objectives and Key Results beneath it.
• If one branch has many stalled Key Results, decide whether the structure is wrong, the connected Initiative canvas is blocked, or the Objective needs a clearer owner.

For a more detailed update, open the Objective or Key Result detail view and read the Check-ins. Tree view shows the structure. Check-ins explain the movement.

Tree view versus List, detail, and Snapshot views

Use List view when you need to scan many rows, edit several Objectives or Key Results, paste multiple Key Results, or work through a table quickly.

Use Tree view when hierarchy is the point of the conversation. It is best for alignment, cascading Objectives, parent-child review, and drag-and-drop structure changes.

Use the detail view when one Objective, Key Result, Initiative, or Check-in needs focused editing.

Use Snapshot when you need a time-based review state. Snapshot is not a live editing surface; it helps the team compare progress for a selected week or review point.

Why teams like Tree view

Tree view makes strategy visible. It is easier to see whether the plan has too many branches, whether one Objective is carrying too much, and whether Key Results are measuring the right part of the work.

It also makes conversations cleaner. Instead of asking people to infer alignment from a long list, the map shows the rollup. That can be especially useful for leadership reviews, cross-functional launch planning, education programs, and any Session where several teams contribute to one outcome.

Example: an alignment review at PocketRN

PocketRN's public customer story is a good example of why Tree view matters. Their team uses ALLO for Goals/OKRs because the visual structure makes OKR review feel less like maintaining a table and more like looking at the shape of the company plan. That distinction is not cosmetic. When people can see the hierarchy, they can talk about alignment before they get lost in row-by-row status updates.

A useful review pattern is to open Tree view before the meeting moves into individual updates. Start zoomed out so the room can see the company or team Objectives. Then zoom into one branch when a Key Result is at risk, a child Objective looks disconnected, or a team is carrying more than its share of the plan.

If the hierarchy is wrong, fix it while everyone can see the surrounding context:

1. Drag the Objective or Key Result into the right parent.
2. Reorder the branch.
3. Pause long enough to ask whether the new structure tells a truer story.

If the hierarchy is right but the work is blocked, open the connected Initiative canvas and review the plan, files, notes, subtasks, and comments there.

This is where cascading OKRs become usable. The hierarchy gives the meeting a shared map. Check-ins explain what changed. Initiative canvases show the work behind the number. Without that combination, teams often end up arguing from memory: one person has a spreadsheet in mind, another remembers a planning doc, and someone else is reading last week's notes. Tree view gives everyone the same object to point at.

Example: moving from list cleanup to strategy review

Imagine a quarterly planning Session with one company Objective, three department Objectives, and ten Key Results. In List view, the team can quickly paste titles, owners, metrics, and initial targets. That is the right place to clean up wording.

Before the Session is finalized, switch to Tree view. Zoom out and look for weirdness:

• Product has five child Objectives while Customer Success has none.
• A Key Result about onboarding time sits under a revenue Objective when it really belongs under customer activation.
• A department Objective is not supporting the company Objective at all; it is just a useful project someone wanted to protect.

Those are strategy problems, not formatting problems. Tree view makes them visible enough to solve. Move the items, simplify the branch, and then return to List or detail view for precise text edits.

Common mistakes

Do not use Tree view as the only editing surface. List and detail views are often better for precise text editing and repeated updates.

Do not create deep hierarchy just because the map supports it. If someone cannot explain the structure in a sentence, it is probably too complex.

Do not drag items while search, filters, or custom sorting are hiding related rows. Clear the view first so you have enough context to make the right move.

Do not put Initiatives into the Objective hierarchy. Initiatives are connected canvases for Objectives or Key Results; they are not child Objectives.

Recover when Tree view looks wrong

If the map looks empty, confirm the Session has Objectives and that filters are not hiding them.

If an Objective appears at the wrong level, check whether it has a parent Objective. Move it in Tree view or List view if you have permission.

If a move does not save, refresh before trying again. The item changed in another tab, changed by another teammate, or lost the context needed for the move.

If Tree view and List view disagree after refresh, capture the Session link, item names, and approximate time, then contact your workspace admin or support. The same Goals/OKRs structure should be reflected across views.