> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Finding Resolution Rate (90d), ClickUp > Finding Resolution Rate (90d) for ClickUp stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Project Management](/nerve-centre/connectors#connectors-by-type) ## At a glance > The percentage of Vortex IQ findings created in ClickUp in the last 90 days that have reached a `closed`-type status. ClickUp's headline strength is its all-in-one configurability; the cost of that configurability is that "resolved" can be hard to define. This card cuts through by reading `status.type` directly: only `closed` is resolved. Below 50% the team is falling behind; above 75% it's keeping up. | | | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **The formula** | `resolved_in_window ÷ created_in_window`, where `resolved_in_window` counts ClickUp tasks with `vortexiq_finding_id`, `status.type = 'closed'`, and `date_closed` (or `date_done` for legacy task variants) within the 90-day window; `created_in_window` counts tasks with the same custom-field set and `date_created` within the same window. | | **API endpoints** | `GET /api/v2/list/{list_id}/task` paged with `archived=false&include_closed=true&order_by=created` and `subtasks=true` for nested findings. We bucket by `vortexiq_finding_id` to avoid double-counting if a finding was re-created. | | **Window** | Rolling 90 days, refreshed hourly. Real-time refreshes happen on every ClickUp webhook event for the live count, but the rate calculation is hourly to smooth single-task volatility. | | **What "resolved" means** | `status.type = 'closed'` only. Statuses with type `open`, `custom`, or `done` are NOT counted as resolved. ClickUp's `done` type is treated as not-yet-resolved because some teams use *Done* as a review-pending state before *Closed*. | | **Won't Do treatment** | A task moved to a custom `closed`-type status named *Won't Do* counts as resolved. We treat both decisions (fix it, decide not to fix it) as resolutions because closing the loop is what the rate measures. | | **Project / List scope** | All `vortex_iq_outbound` Lists across all Spaces in all connected Workspaces. | | **Archived containers** | Excluded from both numerator and denominator. | | **Time zone** | `date_closed` and `date_created` are Unix epoch ms (UTC). The 90-day window aligns to UTC. | | **Alert trigger** | `< 50%` raises a critical alert. | | **Sentiment thresholds** | Gauge: green ≥ 75%, amber 50-74%, red \< 50%. | | **Multi-workspace aggregation** | Yes, computed on summed numerator and denominator. Per-workspace stack panel available. | | **Roles** | owner, operations | ## Calculation Calculated automatically from your ClickUp data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A US-based mid-market apparel brand on BigCommerce, 32-person team. ClickUp is the all-in-one workspace; the brand has four Spaces (Marketing, Catalogue, Engineering, CX) with bespoke status spectrums per Space. Snapshot taken on 02 May 26 at 09:45 EDT. | Last 90 days (02 Feb 26 - 02 May 26) | Count | | ------------------------------------------------------------------------------------- | ----- | | Findings created (ClickUp tasks with `vortexiq_finding_id`, `date_created` in window) | 112 | | Findings resolved (above set, AND `status.type = 'closed'`, `date_closed` in window) | 76 | | Findings still open from window | 30 | | Findings re-created within window (counted once on first close in numerator) | 6 | ```text theme={null} Resolution rate = 76 ÷ 112 = 0.679 = 67.9%, displayed as 68% ``` **What the merchant should read into this:** 1. **68% sits in the amber band (50-74%).** Above the alarm threshold but below the green target. The team is closing more than it is opening, but the open queue shrinks slowly. Acceptable, not great. 2. **The open queue will not collapse to zero.** At 68% resolution rate, expect roughly 25-35 open findings as a steady-state on a 32-person ClickUp team. Anything beyond that is the team falling behind; anything below it is the audit programme finding less than usual. 3. **Pair this card with [Avg Time-to-Fix](/nerve-centre/kpi-cards/clickup/avg-time-to-fix).** A 68% rate with a 7-day mean time-to-fix is healthy. A 68% rate with a 25-day mean time-to-fix means the team is closing the easy items and stalling on the harder ones, the classic ClickUp pattern when custom statuses become parking spaces. 4. **The Engineering Space probably runs higher than 68%; the Marketing Space probably runs lower.** Open the per-Space stack panel to see this breakdown. ClickUp Spaces with strict `closed`-type rules (typical of Engineering with Sprint commitments) usually run 80-90%; Spaces with permissive custom statuses (typical of Marketing with *In Review* and *Awaiting Customer*) usually run 50-65%. The blended rate is an organisation-level number; the per-Space number is operational. 5. **The team should aim for 75% sustained.** Below 50% is alarm territory; above 75% means the team is keeping up with intake. The fastest way to lift a ClickUp rate is to audit the per-Space status taxonomy: any custom status that genuinely means "the team has done its part" should be `closed` type, not `custom` type. ## Sibling cards merchants should reference together | Card | Why pair it with Resolution Rate | What the combination tells you | | -------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | [VortexIQ Findings Open](/nerve-centre/kpi-cards/clickup/vortexiq-findings-open) | Resolution rate's denominator-half. | Falling rate plus climbing open count = capacity bottleneck; falling rate plus flat open count = audit programme finding less. | | [Abandoned Findings (>14d)](/nerve-centre/kpi-cards/clickup/abandoned-findings) | Tasks that count in the denominator but never become numerators. | High abandoned plus low rate equals execution discipline gap; low abandoned plus low rate equals the team is engaged but underwater. | | [Avg Time-to-Fix (days)](/nerve-centre/kpi-cards/clickup/avg-time-to-fix) | Time-to-fix is the cycle time inside this rate. | High rate plus low time-to-fix equals excellent. High rate plus high time-to-fix equals closing eventually but slowly. | | [Tickets Resolved (7d)](/nerve-centre/kpi-cards/clickup/tickets-resolved) | Short-window throughput of all tasks. | High overall throughput but low findings rate equals audit work being deprioritised. | | [Sprint Velocity (avg)](/nerve-centre/kpi-cards/clickup/sprint-velocity) | The team's capacity ceiling. | A flat rate with rising velocity equals audit work not reaching sprints. | | [Throughput Trend](/nerve-centre/kpi-cards/clickup/throughput-trend) | The slope. | A rate dipping while throughput climbs equals deliberate prioritisation away from audit work. | | [Sprint Progress](/nerve-centre/kpi-cards/clickup/sprint-progress) | Whether findings are getting committed to the current sprint. | Low sprint progress + low rate = findings queued but never pulled in. | ## Reconciling against the vendor's own dashboard **Where to look in ClickUp's own UI:** > **[app.clickup.com](https://app.clickup.com)** then open the **Dashboards** module (Unlimited and above). Add a **Tasks completed vs Tasks created** chart, set the time range to *Last 90 days*, and add the filter `Custom Field → vortexiq_finding_id → has any value`. ClickUp's Dashboards also support a **Completion rate** widget (a single percent number) that approximates this card directly; pin it to a workspace dashboard for a side-by-side glance. ClickUp's **Goals** module surfaces a similar completion-rate gauge for goals tied to specific Lists. ClickUp's Dashboard widgets cannot be filtered by `status.type` directly; they filter by status name. This is the most common reason a Dashboard widget rate differs from this card. **Why our number may legitimately differ from a ClickUp Dashboard widget:** | Reason | Direction | Why | | ------------------------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Status-type vs status-name** | Either | We treat `status.type = 'closed'` as resolved. A Dashboard widget filtered "Status is Closed" matches us; a widget filtered "Status is Closed OR Done OR Resolved" will be higher because it counts `done`-type statuses we keep open. | | **Window definition** | Either | ClickUp's Dashboard "Last 90 days" rolls daily at midnight in your account-profile timezone; our window rolls hourly in UTC. | | **Re-created findings** | Ours lower | If a finding was closed, re-opened, and closed again within 90 days, ClickUp's Dashboard counts both completion events; we count once per `vortexiq_finding_id`. | | **Subtask handling** | Either | Our count uses parent tasks (where the custom field lives). ClickUp's chart can be configured to include or exclude subtasks. | | **Archived containers** | Ours lower | Archived Lists/Spaces drop from both numerator and denominator; ClickUp's chart can include archived if configured. | | **Cross-workspace aggregation** | Ours wider | Dashboard widgets are per-Workspace by default; we sum across all connected Workspaces. | **Cross-connector reconciliation. ClickUp resolution rate vs operations-health peers:** | Card | Expected relationship | What causes the divergence | | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`datadog.dd_health_score`](/nerve-centre/kpi-cards/datadog/operational-health-score) | Independent. Datadog Health is server-side production health; ClickUp resolution rate is internal team operations. | A high Datadog Health Score with a low ClickUp resolution rate means production is fine but the team is falling behind on the work that prevents future regressions. The cause-and-effect lag is typically 2-6 weeks. | | [`newrelic.nr_apdex`](/nerve-centre/kpi-cards/newrelic/apdex-score) | Same shape. | Same lag. |
Documentation cross-reference (for agencies running multiple PM tools) The same metric exists with the same definition across other PM tools we connect to. This is **not** a reconciliation, your team uses one PM tool. These references exist purely so an agency running clients on multiple PM tools can cross-link the same metric across docs. * [`asana.asa_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/asana/finding-resolution-rate) * [`basecamp.bas_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/basecamp/finding-resolution-rate) * [`linear.lin_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/linear/finding-resolution-rate) * [`monday.mon_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/monday/finding-resolution-rate) * [`teamwork.tea_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/teamwork/finding-resolution-rate) * [`smartsheet_api.sma_vortexiq_finding_resolution_rate`](/nerve-centre/kpi-cards/smartsheet-api/finding-resolution-rate)
## Known limitations / merchant FAQs **My ClickUp Dashboard widget shows 75% but you say 68%. What's wrong?** Seven points of gap is normal. The usual reasons in order: (1) Status-type vs status-name: we count only `closed` type as resolved; your Dashboard widget filtered by status name may also include `done`-type statuses (which we keep open). (2) Re-opened tasks: ClickUp counts each completion event; we count once per finding-id. (3) Cross-workspace aggregation: we sum across connected Workspaces. (4) Subtask handling. Open the per-Workspace stack panel and the gap usually closes to within 2-3 points. **Does "Won't Do" count as resolved?** Yes, if the *Won't Do* status is type `closed`. From the audit programme's perspective, both decisions are resolutions. Verify the type in **Space Settings → Statuses**, if your *Won't Do* is `custom` rather than `closed`, change it; otherwise it stays counted as open. **ClickUp's `done` and `closed` types are confusing. Which one matters?** Only `closed`. ClickUp's data model has four status types: `open`, `custom`, `done`, `closed`. The `done` type was introduced as an intermediate "ready for review" stage; teams that use *Done* as the final state should change its type to `closed` (this is reversible). The connector reads `status.type` directly, not the status name, so renaming a status without changing its type does nothing. **Our rate sits at 45%. Should I be concerned?** Yes. Below 50% is the alarm threshold. The standard playbook is the four-card investigation: open this card, [Findings Open](/nerve-centre/kpi-cards/clickup/vortexiq-findings-open), [Abandoned Findings](/nerve-centre/kpi-cards/clickup/abandoned-findings), and [Tickets by Assignee](/nerve-centre/kpi-cards/clickup/tickets-by-assignee) side-by-side. Within 5 minutes you'll know if it's a single-assignee bottleneck (most common), a Sprint-planning bottleneck, or a status-taxonomy issue (a Space's *In Review* or *Awaiting Customer* status should probably be type `closed`). **We use multiple ClickUp Workspaces. Which workspace's rate matters most?** The one with the lowest rate is the leading indicator. Open the per-workspace stack panel from the connector drawer to see them broken out. Marketing-led Workspaces typically run lower (50-65%) than Engineering-led Workspaces (80-90%) because of status-taxonomy differences. **Throughput dropped this week, rate is still high. What's happening?** "Team closed everything easy and left the hard stuff." Open [Avg Time-to-Fix](/nerve-centre/kpi-cards/clickup/avg-time-to-fix), if mean cycle time climbed alongside the throughput drop, the team has finished quick-wins and is now starting on heavier findings. Healthy phase, lasts 1-3 weeks. **Today's rate looks volatile. Why?** At low resolution volumes the rate is sensitive: 5 resolutions out of 8 is 62.5% and one extra close moves it to 75%. The 90-day window makes daily volatility small but visible. The 7-day moving rate (shown on the trend line) is less noisy. **Multi-team reporting: how do I see resolution rate by team within one Workspace?** ClickUp's Spaces are the natural team boundary. The per-Space stack panel surfaces the per-team rate. If you need finer-grained "team within Space" reporting (e.g. two product squads sharing one Engineering Space), the workaround is to split into one Folder per squad and tag each Folder as a separate `vortex_iq_outbound` route in connector setup. **Is ClickUp the right tool for tracking this metric?** For mid-market ecommerce teams that want one tool to do everything, yes. ClickUp's per-task time-tracking, goal-linking, and document attachments make it a natural fit when ops, marketing, and engineering all share one workspace. The cost is configuration overhead: the more custom statuses you create, the more decisions Vortex IQ needs about which count as resolved. Asana is closer for cross-functional ops/marketing teams that want portfolios; Linear is closer for engineering-only teams that want cycle-time metrics; Monday is closer for visual-planning teams; Smartsheet is closer for spreadsheet-style PMOs. ClickUp's strength here is the breadth: this card sits comfortably alongside time-tracking and goal cards on a single ClickUp dashboard. **Resolution rate climbed but I don't think the team did anything different. What changed?** Three usual causes. (1) Audit programme produced fewer findings (denominator shrank). Check [Findings Open](/nerve-centre/kpi-cards/clickup/vortexiq-findings-open) trend. (2) A bulk closure (the team did an "abandoned review"). Check ClickUp's Audit Log under **Workspace Settings**. (3) A status type was changed from `custom` to `closed` for an existing custom status; tasks in that status now count as resolved overnight. Check **Space Settings → Statuses** edit history. *** ### Tracked live in Vortex IQ Nerve Centre *Finding Resolution Rate (90d)* is one of hundreds of KPI pulses Vortex IQ tracks across ClickUp and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.