How to build Front support dashboards in Metabase

Front turns shared inboxes — support@, help@, and more — into a collaborative workspace across email, chat, and SMS. 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 Front 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 Front to Metabase?

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

• Conversation volume — opened vs. archived by day, inbox, and channel
• Time to first reply — how long customers wait for a teammate response
• SLA breaches — conversations over your response targets
• Backlog and aging — open work and how long it's been waiting
• Teammate workload — assignments and handle time across the team
• Topic drivers — volume and resolution speed by tag
• Collaboration — internal comments per conversation

Which Front dashboards should you build in Metabase?

How do you build the Front → Metabase pipeline?

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

Connector options

• dlt (free, code) — write a Python pipeline against the Front REST API for full control of streams and schema. The lightest path to a maintainable, no-vendor sync.
• Front REST API (free, raw) — the source of truth; paginate conversations, messages, and events and upsert on a schedule.
• Front Analytics export (free, raw) — Front's built-in analytics can export aggregates; the API gives you row-level detail for custom modeling.
• Fivetran (paid, managed) — offers a Front connector covering conversations, messages, contacts, and inboxes.

Notes

• Land raw tables first, then build clean models on top.
• Sync the conversation events stream if you want accurate time-in-status and reopen analysis.
• Use the message is_inbound flag to separate customer and teammate messages.

Can you generate a Front dashboard with AI?

Yes — and once Front 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 Front Inbox Overview dashboard

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

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

Goal: Help support leaders understand inbox volume, response time, SLA, teammate
workload, and topic drivers from Front data.

First, inspect the schema and identify the available Front tables. Do not assume
exact table names. Map the available raw tables into these analytical concepts
where possible: Conversations, Messages, Comments (internal notes), Contacts,
Teammates, Inboxes, Channels, and Tags.

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 message from a teammate, excluding
  internal comments and automated messages.
- If conversation event history is missing, do not calculate time-in-status or
  reopen rate. Use a caveat instead.
- Do not claim Metabase connects natively to Front unless that is explicitly
  true in this environment.

Dashboard title: Front Inbox Overview

Sections:
1. Executive summary (KPI cards): Conversations opened last 7 days; Archived last
   7 days; Open backlog; Median time to first reply; Volume by channel.
2. Volume & backlog: Opened vs archived by day; Open by inbox; Backlog aging;
   Volume by channel.
3. Response time & SLA: First reply time p50/p90 by week; Over-target by inbox;
   Reopened by week (only if event history exists).
4. Teammate workload: Archived by teammate; Open assigned by teammate; Median
   handle time by teammate.
5. Topics & drivers: Volume by tag; Slowest tags; Volume by contact account.

Filters: Inbox, Teammate, Channel, Tag, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_front_conversations, modeled_front_messages, modeled_front_contacts,
modeled_front_teammates, and modeled_front_inboxes.

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

Core tables

Modeling advice

• Define first reply as the first outbound, non-draft message from a teammate.
• Normalize status into open/snoozed/archived so charts stay stable.
• Treat tags as a bridge table so a conversation can carry many tags.
• Exclude internal comments from response-time math — they're collaboration, not customer replies.
• Define "archived" (resolved) once and reuse it everywhere.

Which Front metrics should you track in Metabase?

What SQL powers Front 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 opened,
  COUNT(*) FILTER (WHERE c.status = 'archived')   AS archived
FROM conversations c
WHERE c.created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

WITH first_outbound AS (
  SELECT
    m.conversation_id,
    MIN(m.created_at) AS first_reply_at
  FROM messages m
  WHERE m.is_inbound = false
    AND m.is_draft = false
  GROUP BY m.conversation_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 conversations c
JOIN first_outbound f ON f.conversation_id = c.id
GROUP BY 1
ORDER BY 1;

SELECT
  i.name             AS inbox,
  COUNT(*)           AS open_conversations
FROM conversations c
JOIN inboxes i ON i.id = c.inbox_id
WHERE c.status = 'open'
GROUP BY i.name
ORDER BY open_conversations DESC;

SELECT
  tg.name            AS tag,
  COUNT(*)           AS conversations
FROM conversations c
JOIN conversation_tags ct ON ct.conversation_id = c.id
JOIN tags tg ON tg.id = ct.tag_id
WHERE c.created_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY tg.name
ORDER BY conversations DESC
LIMIT 20;

What are common mistakes when analyzing Front in Metabase?

Related

Related analytics

Related integrations

FAQ