How to build Drag inbox dashboards in Metabase

Drag turns Gmail and Google Workspace into a shared inbox and help desk with kanban boards, cards, and tags. Metabase is where you turn that activity into shared, trustworthy dashboards. Because Metabase reads from SQL databases, the reliable way to connect them is a small pipeline: sync Drag into a database or warehouse on a schedule, then point Metabase at it. This guide walks through that path end to end — including a free option with no paid connector.

How do you connect Drag to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Drag connector. So connecting Drag to Metabase means one thing: run a small pipeline that copies Drag data into a database on a schedule, then connect Metabase to that database. Once the data lands, the models, metrics, and SQL later in this guide all work.

The good news: this doesn't require a paid tool. Use a managed connector if you want zero maintenance, or a free, code-based sync you host yourself — both are covered in Build the pipeline below, and in more depth in our guide to building a data pipeline.

What can you analyze from Drag data in Metabase?

• Card volume — created vs. closed by day and board
• Time to first reply — how long customers wait for a response
• Board and column health — backlog by shared inbox and status
• Backlog and aging — open cards and how long they've been waiting
• Team workload — assignments and emails sent per member
• Tag drivers — volume and resolution speed by tag
• Contacts — new vs. returning senders

Which Drag dashboards should you build in Metabase?

How do you build the Drag → Metabase pipeline?

For dashboards that need history and reliability, land Drag data in a database first, then connect Metabase to that database.

Connector options

• dlt (free, code) — wrap the v2 API in a Python pipeline for incremental loads and schema control. The lightest path to a maintainable sync.
• Drag REST API (v2) (free, raw) — the source of truth; read boards, cards, tags, and contacts. The base URL is v2/ with API-key auth and a rate limit around 100 requests/minute.
• Webhooks — Drag includes webhooks; subscribe to card events to keep your warehouse fresh in near real time.

Notes

• Land raw tables first, then build clean models on top.
• Respect the rate limit — page and back off rather than hammering the API for large historical loads.
• Sync email-level data so you can compute reply times, not just card counts.

Can you generate a Drag dashboard with AI?

Yes — and once Drag data is synced into a database, this is the fastest way to a strong first draft. First give an AI assistant a way to read your Metabase schema and create questions and dashboards, then paste the prompt below. It builds the dashboard from your database tables and tells the agent to skip metrics the schema can't support instead of faking them.

Two ways to let an assistant query and build in Metabase

Both connect to a Metabase instance that's already pointed at your synced database — the pipeline above moves the data; these just let the assistant read and write Metabase. Pick whichever fits your setup:

Set up the Metabase MCP server

Enable it under Admin → AI → MCP, then point your client at the endpoint:

# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp

{
  "mcpServers": {
    "metabase": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://your-metabase.example.com/api/metabase-mcp"]
    }
  }
}

Clients with native remote support can use a "url" field instead of the mcp-remote bridge. Confirm the current endpoint in the Metabase MCP docs.

Set up the Metabase CLI

Install it globally, then authenticate once (the binary is mb):

# Install the CLI (the binary is `mb`)
npm install -g @metabase/cli

# Authenticate once — opens your browser on Metabase v62+, or use an API key
mb auth login --url https://your-metabase.example.com
mb auth status

On Metabase v62+ mb auth login opens your browser; older servers fall back to an API key. A terminal-based assistant can then inspect your schema (mb db schemas, mb table get --include fields) and create content (mb card create, mb dashboard create) against the synced tables.

Prompt: build the Drag Inbox Overview dashboard

With MCP or the CLI connected, paste this into your assistant to generate the dashboard:

Create a polished Metabase dashboard for Drag shared-inbox analytics using the
available Drag tables in this database.

Goal: Help team leads understand inbox volume, response time, workload, and tag
drivers from Drag (Gmail shared inbox) data.

First, inspect the schema and identify the available Drag tables. Do not assume
exact table names. Map the available raw tables into these analytical concepts
where possible: Boards (shared inboxes), Cards (conversations), Columns (statuses),
Threads/Emails, Tags, Users, and Contacts.

Important:
- Build the dashboard from durable database/warehouse tables.
- Use medians (p50) and p90 for reply times, never averages.
- Define "first reply" as the first outbound email from a team member, excluding
  internal notes and automated messages.
- If card movement history is missing, do not calculate time-in-column or reopen
  rate. Use a caveat instead.
- Do not claim Metabase connects natively to Drag unless that is explicitly true
  in this environment.

Dashboard title: Drag Inbox Overview

Sections:
1. Executive summary (KPI cards): Cards created last 7 days; Closed last 7 days;
   Open backlog; Median time to first reply; Volume by board.
2. Volume & backlog: Created vs closed by day; Open by column; Backlog aging;
   Volume by board.
3. Response time: First reply p50/p90 by week; Cards by tag; Reopened by week
   (only if history exists).
4. Team workload: Closed by assignee; Open assigned by assignee; Emails sent by
   member; Median handle time by assignee.
5. Tags & drivers: Volume by tag; Slowest tags; New vs returning contacts;
   Volume by hour.

Filters: Board, Assignee, Tag, Column/status, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_drag_cards, modeled_drag_boards, modeled_drag_emails,
modeled_drag_users, and modeled_drag_contacts.

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 schema. Keep it practical, dense,
and executive-readable. Avoid vanity metrics.

How should you model Drag data in Metabase?

Core tables

Modeling advice

• Treat a card as the conversation/ticket grain for most dashboards.
• Define first reply from the first outbound, non-note email on a card.
• Map columns to a small status set (open/in-progress/done) so charts stay stable.
• Treat tags as a bridge table so a card can carry many tags.
• Define "closed" once and reuse it everywhere.

Which Drag metrics should you track in Metabase?

What SQL powers Drag dashboards in Metabase?

These assume the modeled tables above (PostgreSQL dialect). Adjust identifiers to match your warehouse.

SELECT
  date_trunc('day', c.created_at) AS day,
  COUNT(*)                                          AS created,
  COUNT(*) FILTER (WHERE c.is_closed = true)        AS closed
FROM cards c
WHERE c.created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

WITH first_outbound AS (
  SELECT
    e.card_id,
    MIN(e.sent_at) AS first_reply_at
  FROM emails e
  WHERE e.direction = 'outbound'
    AND e.is_note = false
  GROUP BY e.card_id
)
SELECT
  date_trunc('week', c.created_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (f.first_reply_at - c.created_at)) / 60.0
  ) AS median_first_reply_min
FROM cards c
JOIN first_outbound f ON f.card_id = c.id
GROUP BY 1
ORDER BY 1;

SELECT
  b.name             AS board,
  COUNT(*)           AS open_cards
FROM cards c
JOIN boards b ON b.id = c.board_id
WHERE c.is_closed = false
GROUP BY b.name
ORDER BY open_cards DESC;

SELECT
  u.name             AS assignee,
  COUNT(*) FILTER (WHERE c.is_closed = false) AS open_cards,
  COUNT(*) FILTER (WHERE c.is_closed = true)  AS closed_cards
FROM cards c
JOIN users u ON u.id = c.assignee_id
WHERE c.created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY u.name
ORDER BY open_cards DESC;

What are common mistakes when analyzing Drag in Metabase?

Related

Related analytics

Related integrations

FAQ