How to Build a Live GTM Dashboard With Claude Code Artifacts

What actually changed

I have been building throwaway dashboards in Claude Code for about a year. Pull the pipeline data, render a table or a chart, ship the artifact, and it looks great for exactly as long as nobody refreshes the page. The moment a rep closes a deal or a lead gets enriched, the artifact is stale, and the only fix was rerunning the session and republishing.

Anthropic closed that gap in the July 13 to 17, 2026 Claude Code update. Per the official what's new digest, "a published artifact can pull live data and take actions through each viewer's own MCP connectors when they open the page." The same week added public sharing links, editor roles on Team and Enterprise plans, and artifacts created directly from Tag sessions.

Anthropic's developer account described the practical version of this on X: "Claude Code artifacts can now call MCP connectors, letting you build dashboards and apps that can fetch information and take actions for each viewer on demand. Available on Pro, Max, Team, and Enterprise plans. Not available on publicly-shared artifacts."

Why this matters for GTM tooling

Most GTM teams do not lack dashboards. They have three of them, in three tools, all showing slightly different numbers because each one snapshotted the data at a different time. The pitch here is not "a new chart type," it is that the artifact itself becomes the live view, built and maintained by whoever in the org can run a Claude Code session, not a dedicated dashboard team.

For a GTM engineer, that turns a category of internal tools, pipeline coverage, lead routing status, meeting-to-opportunity conversion by rep, from a one-off export into something you build once and reference for months, without a separate BI subscription or a data engineer on standby to keep it patched.

Before you start

You need a few things in place before this is worth the build time:

• Claude Code on a Pro, Max, Team, or Enterprise plan. Connector calls from artifacts are not part of the free tier.
• At least one MCP connector already authenticated to the system you want live data from, your CRM, your data warehouse, or an internal API.
• A specific question the dashboard answers. "Show me pipeline" is not a dashboard, it is a request for a data dump. "Show me deals with no activity in 10 days, grouped by owner" is a dashboard.
• If you are on Team or Enterprise, know who owns the Artifacts permission under Settings and Roles, because public sharing is off by default and someone with Owner access has to turn it on.

Pick your data source

Start narrow. The most useful version of this I have built is not a general pipeline overview, it is a single-purpose view: stalled deals, leads sitting unrouted, or reply-to-meeting conversion by sequence. Pick the MCP connector that already has read access to that data, your CRM connector, an enrichment vendor's connector, or a warehouse connector if the numbers already live in a table somewhere.

Resist the urge to wire in five data sources on the first pass. Every connector you add is another authentication step for every future viewer, and another thing that can silently fail to load for someone who has not connected that source yet.

Build the artifact

Describe the view you want to Claude Code the same way you would describe it to a person: what data, what filters, what the layout should look like. Ask it to render as an Artifact rather than just printing a table in the terminal. On the first pass, let it use the data available in the session, then confirm the shape and the filters are right before you wire in the live connector call.

I build these the same way I build any internal tool: get the static version right first, because it is much easier to debug a wrong filter on a snapshot than on a live feed that keeps changing under you.

Wire the connector call

Once the layout is right, tell Claude Code to have the published artifact call the connector directly on load instead of embedding the data it pulled during the session. This is the actual new behavior: the artifact's code runs a connector query every time a viewer opens the page, using that viewer's own authenticated connection, not a copy of data from when you built it.

Test this part yourself before you share it. Open the artifact fresh, confirm it prompts you to approve connector access on first load, and check that the numbers match what you would get querying the source system directly.

Handle per-viewer auth

This is the detail that makes the feature safe enough to hand to a team instead of just keeping it as your own tool. Each viewer authenticates their own connector, so the artifact is not a shared credential leaking CRM access to everyone who gets the link. A rep who opens your stalled-deals dashboard sees data through their own CRM permissions, not through yours.

Practically, that means a colleague with no CRM access, or restricted access, will see errors or partial data the first time they open it, not silently see everything you can see. Tell people that before you share the link, or the first support question you get will be "why is it broken" when it is actually working exactly as designed.

Add actions, not just views

The same connector wiring that fetches data can take actions, which is the part most teams skip on the first build. A stalled-deals dashboard is more useful with a button that reassigns an owner or logs a follow-up task than as a read-only list someone still has to act on inside the CRM separately.

Start read-only. Add one action at a time, and only once you trust the view is pulling correct data. An artifact that can write back to your CRM is a small program, and it deserves the same "does this do what I think it does" scrutiny you would give any script that touches production data.

Share it with editor roles

Team and Enterprise plans added editor roles for shared artifacts in the same update. In practice, that means you can hand a colleague edit access to adjust filters or layout without giving them your Claude Code session, and everyone with the page open sees updates live. Reserve editor access for people who will actually maintain the thing, viewer access for everyone else who just needs the number.

Public sharing links exist now too, but remember they do not get live connector data. A public link is the right call for a static snapshot you want outside the org, an internal live dashboard should stay inside your organization's sharing settings.

A short governance checklist

Before you point one of these at anything resembling production CRM data, run through this:

• Confirm the connector's underlying permission scope matches what you actually want a viewer to see, not just what happens to be convenient.
• Decide who gets editor access up front, and revisit it, because artifact edit access tends to accumulate quietly the way shared spreadsheet edit access always has.
• If your org has role-based access control on Enterprise, scope the Artifacts permission under Settings and Roles rather than leaving it wide open by default.
• Write down, somewhere a new hire can find it, what each live dashboard actually queries and what actions it can take, since "what does this button do" is a bad question to answer for the first time during an incident.

Live artifact vs a BI tool vs a spreadsheet export

I do not think this replaces a real BI tool for company-wide reporting, board decks, or anything that needs a governed semantic layer across many teams. What it replaces is the narrower, faster category: the dashboard one person builds for their own pod, that used to live as a half-maintained spreadsheet or a Looker view nobody remembers how to edit. That category is bigger than most GTM teams admit, and it is exactly where a GTM engineer's time goes.

Where this fits in my own stack

I run my own outbound tooling on a Forge stack, Salesforge for sending and Leadsforge for lead data, and this update slots in as the reporting layer on top rather than replacing any of it. A live artifact pulling reply and meeting data through an MCP connector to whichever CRM I am running that week is a faster way to check "is this sequence actually working" than exporting a CSV every Monday.

My honest take

This is a genuinely useful feature and a small one, which is usually the sign a product update is real rather than a headline. It will not replace your CRM's native reporting and it should not replace a proper BI tool once more than a handful of people depend on a number. But for the internal, single-purpose view that a GTM engineer builds for their own team, it removes the main reason those views used to go stale: nobody wants to rerun a session every morning just to refresh a chart.

FAQ