Run your quarterly OKR review board on ClickUp Goals

Build an internal app that my leadership team opens during our weekly business review to run our quarterly OKRs out of ClickUp Goals. The problem it solves is that goal progress is buried in ClickUp and ClickUp shows a current percentage without showing whether that percentage is ahead of or behind where we should be this far into the quarter, so nobody trusts the numbers when we get to the meeting. The audience is a founder, COO, or department head running the review, with each goal owner updating their own key results live.

The main view is a board listing every goal in the workspace, loaded with the ClickUp Get Goals operation. Goals live at the workspace level, and in ClickUp API v2 the word team means workspace, so scope the board to one workspace ID that the user picks on first load and the app remembers afterwards. Get Goals returns every goal in a single response with no pagination. Each row shows the goal name, its owners, the due date, and the overall progress percentage.

Next to progress, show pace. For each goal, compute how much of the quarter has already elapsed as a percentage of the window between the goal's start date and its due date, and display that percentage right beside actual progress. All ClickUp timestamps are Unix epoch milliseconds, so convert before doing any date math. When progress trails elapsed time by more than a configurable threshold, default 10 percentage points, flag the goal as At risk automatically; otherwise label it On pace or Ahead. Sort at-risk goals to the top of the board and expose the threshold as a setting.

Load key results for a goal with the Get Goal operation, which returns the goal's key results with their current value and target value. Render each key result as a row showing current against target, the percent complete that implies, and the same pace comparison used at the goal level. Handle the different key result types ClickUp supports, including number, currency, percentage, boolean, and automatic key results tied to tasks, and format each one appropriately rather than printing raw values.

Clicking a goal opens a detail pane containing its key results plus the ClickUp tasks backing that goal, pulled with Get Filtered Team Tasks scoped to the Lists or tags tied to the goal. Give the user a small control for mapping a goal to one or more Lists and tags, populating the List picker with Get Lists, and persist that mapping per goal so the meeting never has to reconfigure it. Show each task with its status, assignee, and due date, plus a rollup of how many are complete versus still open, so we can see whether the underlying work is actually moving or the number is just being typed in. Get Filtered Team Tasks is paginated at 100 tasks per page, so page through until the results are exhausted.

During the meeting the app has to be editable, not just readable. From the detail pane, let the goal owner update a key result's current value with Update Key Result, change a goal's owner or due date with Update Goal, and add a brand new key result mid quarter with Create Key Result. Note that Update Goal expects owners as separate add and remove lists rather than one replacement array. Every edit writes straight back to ClickUp and then refreshes the affected goal and its pace flag, so the board is accurate the moment a number changes.

Keep a running change log for the session recording each edit as goal, field, previous value, new value, who made it, and when. At the end of the meeting a Post recap button sends a Slack message to our leadership channel listing the goals currently flagged at risk and every change made during the session. Let the user choose the channel once and remember it, and show a preview of the recap before it sends.

Persist the selected workspace ID, the at-risk threshold, the goal to Lists and tags mappings, the chosen Slack channel, and the current session change log. Everything else reads live from ClickUp each time the board is opened, so the meeting always starts from current data.