How to build Plain support dashboards in Metabase

Plain is an API-first B2B support platform — a GraphQL API and a typed SDK are first-class, not afterthoughts. 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 Plain 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 Plain to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Plain connector. So connecting Plain to Metabase means one thing: run a small pipeline that copies Plain 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 Plain data in Metabase?

• Thread volume — created vs. resolved by day and channel
• Time to first response — overall and by tenant
• SLA status — threads within and outside target
• Tenant health — open threads and load by company
• Backlog and aging — open work and how long it's been waiting
• Drivers — volume by label and custom thread field
• Channel mix — email, chat, and API-created threads

Which Plain dashboards should you build in Metabase?

How do you build the Plain → Metabase pipeline?

Every pipeline is the same four stages: extract from Plain's API, load into a database, model the raw tables into clean ones, and visualize in Metabase. You can assemble this with a managed connector or a free script you host yourself.

Connector options

• dlt (free, code) — wrap the GraphQL API in a Python pipeline for incremental loads and schema control. The lightest path to a maintainable, no-vendor sync.
• Plain GraphQL API (free, raw) — the source of truth; query threads, timeline entries, customers, and tenants and upsert on a schedule. Plain advertises no restrictive rate limits.
• Typed SDK (free) — Plain ships an open-source TypeScript SDK you can use to build a custom sync job.
• Webhooks (free) — subscribe to thread events to keep your warehouse fresh in near real time.

Notes

• Land raw tables first, then build clean models on top.
• Sync timeline entries (not just threads) so you can compute response and resolution times.
• Bring tenants and thread fields into your model for per-account analysis.

Can you generate a Plain dashboard with AI?

Yes — and once Plain 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 Plain Support Overview dashboard

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

Create a polished Metabase dashboard for Plain support analytics using the
available Plain tables in this database.

Goal: Help support and customer success leaders understand volume, responsiveness,
SLA, tenant health, and contact drivers from Plain data.

First, inspect the schema and identify the available Plain tables. Do not assume
exact table names. Map the available raw tables into these analytical concepts
where possible: Threads, Timeline entries (messages/events), Customers, Tenants
(companies), Labels, Thread fields, and SLA status if present.

Important:
- Build the dashboard from durable database/warehouse tables.
- Use medians (p50) and p90 for response times, never averages.
- Plain models companies as tenants — roll metrics up to the tenant where useful.
- Define "first response" as the first outbound message from a human or machine
  user, excluding internal notes.
- If timeline history is missing, do not calculate time-in-status. Use a caveat
  instead.
- Do not claim Metabase connects natively to Plain unless that is explicitly
  true in this environment.

Dashboard title: Plain Support Overview

Sections:
1. Executive summary (KPI cards): Threads created last 7 days; Resolved last 7
   days; Open backlog; Median time to first response; SLA status; Volume by
   channel.
2. Volume & backlog: Created vs resolved by day; Open by status; Backlog aging;
   Volume by channel.
3. Tenant health: Open threads by tenant; Tenants with rising volume; Response
   time by tenant; Top tenants by load.
4. SLA & response time: SLA status breakdown; First response p50/p90 by week;
   Reopened by week (only if history exists).
5. Drivers: Volume by label; Threads by custom field; Feature requests by tenant.

Filters: Tenant, Channel, Label, Assignee, Status, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_plain_threads, modeled_plain_timeline_entries, modeled_plain_customers,
and modeled_plain_tenants.

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 Plain data in Metabase?

Core tables

Modeling advice

• Roll threads up to the tenant for B2B account-health dashboards.
• Normalize status (todo/snoozed/done) and channel so charts stay stable.
• Use actor_type on timeline entries to separate human, machine (AI), and customer messages for honest response metrics.
• Treat labels as a bridge table so a thread can carry many labels.
• Define "done" once and reuse it everywhere.

Which Plain metrics should you track in Metabase?

What SQL powers Plain dashboards in Metabase?

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

SELECT
  date_trunc('day', t.created_at) AS day,
  COUNT(*)                                          AS created,
  COUNT(*) FILTER (WHERE t.status = 'done')         AS resolved
FROM threads t
WHERE t.created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

SELECT
  tn.name            AS tenant,
  COUNT(*)           AS open_threads
FROM threads t
JOIN tenants tn ON tn.id = t.tenant_id
WHERE t.status <> 'done'
GROUP BY tn.name
ORDER BY open_threads DESC
LIMIT 25;

WITH first_outbound AS (
  SELECT
    e.thread_id,
    MIN(e.created_at) AS first_reply_at
  FROM timeline_entries e
  WHERE e.entry_type = 'message'
    AND e.direction = 'outbound'
  GROUP BY e.thread_id
)
SELECT
  date_trunc('week', t.created_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (f.first_reply_at - t.created_at)) / 60.0
  ) AS median_first_reply_min
FROM threads t
JOIN first_outbound f ON f.thread_id = t.id
GROUP BY 1
ORDER BY 1;

SELECT
  l.label_type       AS label,
  COUNT(*)           AS threads
FROM threads t
JOIN thread_labels tl ON tl.thread_id = t.id
JOIN labels l ON l.id = tl.label_id
WHERE t.created_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY l.label_type
ORDER BY threads DESC
LIMIT 20;

What are common mistakes when analyzing Plain in Metabase?

Related

Related analytics

Related integrations

FAQ