How to build Twenty CRM sales dashboards in Metabase

{
  "mcpServers": {
    "twenty": {
      "url": "https://mcp.pipedream.net/v2"
    }
  }
}

# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load a Twenty CSV export — creates a table AND a model
mb upload csv --file twenty-opportunities.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file twenty-opportunities.csv

Create a polished Metabase dashboard for Twenty CRM sales analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help sales leaders understand pipeline, win rate, conversion, sales cycle,
and relationship coverage from Twenty CRM data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Twenty tables and
  models, and any connected Twenty Postgres database). If durable data is already
  present — a direct read replica or uploaded earlier — use it and skip to Step 2.
- If nothing is there, pull it with the Twenty MCP server (scope the connection to
  read-only where possible): opportunities, companies, people, and activity. Write
  each result to a CSV, then load it with the Metabase CLI — run
  "mb upload csv --file <export>.csv" so each upload creates a table and a
  ready-to-query model. Use "mb upload replace <table-id> --file <export>.csv" to
  refresh an existing table instead of creating duplicates.

Step 2 — Inspect before querying:
Twenty stores each workspace in its own Postgres schema and supports custom
objects, so do not assume exact table or column names. CSV exports are usually
flat and pre-aggregated (one row per opportunity), while the direct Postgres
tables are raw. If connected directly to Twenty's Postgres, treat it as a read
replica and build on modeled views, not raw tables. Inspect the actual tables and
column names first.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Twenty's SaaS — it reads a database (Twenty's own Postgres) or CLI-uploaded
  tables.
- Define "won" and "closed" once (from the opportunity stage) and reuse them.
- For win rate, state the denominator explicitly (won / closed vs. won / created)
  and hold the cohort fixed.
- Report sales cycle length and deal size as medians (p50) and p90, never plain
  averages — both are right-skewed.
- Only compute sales cycle length, time-in-stage, or stage conversion when
  stage-change history exists; otherwise use a caveat.
- Twenty stores money as amountMicros (value x 1,000,000) plus a currencyCode —
  divide by 1,000,000 and convert to a single reporting currency; caveat any mix.
- Only build a card if its underlying column/metric exists in the data.
- A single CSV is a point-in-time snapshot: only build trend cards if there is a
  usable date column or multiple periods have been uploaded.

Dashboard title: Twenty Sales Overview

Sections:
1. Executive summary (KPI cards): Open pipeline; Coverage vs. target; Win rate
   (last 90 days); Median sales cycle length; Average and median deal size;
   Opportunities closing this period.
2. Pipeline: Open opportunities by stage; value by owner and company; stale
   opportunities.
3. Conversion: Stage-to-stage conversion; win rate by segment and source; lost
   reasons.
4. Velocity: Median cycle length; time-in-stage; deal velocity; aging.
5. Relationships: Companies by segment; new records by week; records with an open
   opportunity.

Filters: Stage, Owner, Segment, Source, Date range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a read replica
or warehouse) create reusable models: modeled_twenty_opportunities,
modeled_twenty_stage_history, modeled_twenty_companies, modeled_twenty_people,
and modeled_twenty_activity.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available data. Keep it practical, dense,
and executive-readable. Avoid vanity metrics.

Won as a share of closed opportunities over the last 12 months.

SELECT
  date_trunc('month', o.close_date) AS month,
  COUNT(*) FILTER (WHERE o.stage = 'WON')                    AS won,
  COUNT(*) FILTER (WHERE o.stage IN ('WON', 'LOST'))         AS closed,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE o.stage = 'WON')
      / NULLIF(COUNT(*) FILTER (WHERE o.stage IN ('WON', 'LOST')), 0),
    1
  ) AS win_rate_pct
FROM modeled_twenty_opportunities o
WHERE o.stage IN ('WON', 'LOST')
  AND o.close_date >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;

The current funnel — open opportunities and value by stage.

SELECT
  o.stage,
  COUNT(*)                          AS open_opportunities,
  ROUND(SUM(o.amount_micros / 1e6), 2) AS open_value
FROM modeled_twenty_opportunities o
WHERE o.stage NOT IN ('WON', 'LOST')
GROUP BY o.stage
ORDER BY open_value DESC;

Days from created to won; medians beat averages here.

-- Median days from created to won, by month closed
SELECT
  date_trunc('month', o.close_date) AS month,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (o.close_date - o.created_at)) / 86400.0
  ) AS median_cycle_days,
  percentile_cont(0.9) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (o.close_date - o.created_at)) / 86400.0
  ) AS p90_cycle_days
FROM modeled_twenty_opportunities o
WHERE o.stage = 'WON'
GROUP BY 1
ORDER BY 1;