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. This guide covers two complementary paths: a lightweight MCP route for fast, AI-assisted questions, and a durable pipeline route that syncs Front into a database so you can build dashboards anyone can read.

How do you connect Front to Metabase?

Most teams combine these: use the MCP route to explore and triage, and the pipeline route for the dashboards people depend on.

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 use the Front and Metabase MCP servers together?

Pair the Front MCP server with the Metabase MCP server for live, conversational analysis. The Front MCP reads current inbox data as you; the Metabase MCP queries the models and dashboards you've already built.

Example workflows

• List unanswered conversations in the support inbox and summarize by tag.
• Pull today's open conversations from Front and compare response trends against a Metabase model.
• Draft a reply to a waiting customer, then log the interaction.

Be honest about the limits

• MCP is great for live lookups — not for scheduled or audited reporting.
• It does not create history; trend analysis still needs synced data.
• Front's MCP is user-scoped — every action attributes to the authorizing teammate and respects their permissions.
• The Metabase MCP server is built in; an admin enables it under Admin → AI → MCP.

How do you set up the Front and Metabase MCP servers?

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

On first connection each server opens a browser window to authorize. Front admins can limit which read/write/send permissions the MCP server may use.

Can you generate a Front dashboard with AI?

Yes — and this is the fastest way to a strong first draft. Use the prompt below with the Metabase MCP server and any assistant that can inspect your warehouse schema and create Metabase questions. It assumes Front data is already synced into a database Metabase can read, treats MCP as exploratory, and tells the agent to skip metrics the schema can't support instead of faking them.

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:
- Treat MCP data access as exploratory only.
- 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 do you sync Front data into a database or warehouse?

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

Connector options

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

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.

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