Boreon MCP Layer
It publishes only what it can prove.
The engine checks its own work. Every number on a migrated dashboard is compared with Tableau's answer through the VizQL Data Service. If one can't be matched, nothing gets published, and the agent tells you why in natural language.
Measured live on a real Tableau workbook: DBX Platform Latency Calls & Uptime, moved to Databricks.
- 3 / 3
- sheets identical to Tableau
- 96%
- fidelity score
- 20M
- rows in the view, built in 72 s
- 0
- SQL errors on publish
Watch a real migration run.
Migrate DBX Platform Latency Calls & Uptime to Databricks
- Read the workbook Dashboard “Databricks Latency Dashboard” · 3 sheets · shelves, filters, calculations 3 sheets
- Found the Prep flow behind it Data source bi_usage_events_databricks is a flow output on Databricks 1 flow
-
Flow to materialized view
One SQL statement, one CTE per flow step
CREATE MATERIALIZED VIEW bi.usage_events_mv AS WITH clean AS (…), joined AS (…) SELECT … FROM joined20M rows · 72 s - Every sheet proven on Databricks Each sheet's query runs before anything is published 0 SQL errors
- Numbers checked against Tableau VizQL Data Service parity, row by row 41 / 41 rows
- Published as a Databricks AI/BI dashboard Fidelity shown per sheet 96%
Published. The customer only typed the first line.
How a migration runs.
You type one line. The layer does the rest and shows its work as it goes.
-
01
Read the workbook
Shelves, filters and calculations. 3 sheets.
-
02
Find the Prep flow
The flow behind its data source. 1 flow.
-
03
Turn the flow into a view
One SQL statement, one CTE per step. 20M rows in 72 s.
-
04
Prove every sheet
Each query runs before publish. 0 SQL errors.
-
05
Check the numbers
Against Tableau's own answer. 41 of 41 rows.
-
06
Publish
A Databricks AI/BI dashboard, at 96% fidelity.
Proof comes with every migration.
Measured on your own workbooks, and shown to you before anything is published.
-
A fidelity report per sheet
What was mapped, approximated or left out, with a score.
-
Parity with Tableau
Each sheet's rows compared with Tableau's own answer.
-
Queries proven first
Every sheet runs on the warehouse before anything is published.
-
A reason for anything it skips
If it won't migrate something, it names it and says why.
| Sheet | Rows matched |
|---|---|
| Sheet 1 | 12 / 12 |
| Sheet 2 | 5 / 5 |
| Sheet 3 | 24 / 24 |
| 3 / 3 | 41 / 41 |
All 41 rows match · published
The grounding gate comes first.
A Tableau data source converts only when its data is real from end to end. If a single field is missing, the whole data source waits, and the plan tells you which fields to add.
Tableau Server or Tableau Cloud
Sales Overview
- Revenue by region
- Pipeline trend
- Top accounts
The grounding gate
- Maps to the Sales semantic model
- 12 of 12 fields are in the model
- 48,210 real rows behind it
Tableau Next · Sales workspace
- Revenue by regionVisualization
- Pipeline trendVisualization
- Top accountsVisualization
- Sales OverviewDashboard
Sharing carried overManagerEditorViewer
Live, after a person approved it
-
It maps to a semantic model
Each data source is matched to a Data 360 semantic model: the one built on that same data, or the one you name.
-
Every field is in the model
Every field the workbook uses has to be in that model. One missing field holds back the whole data source.
-
The data is real
The model has to answer a query, with real rows behind it, counted live.
Plan it, rehearse it, then a person says go.
A Tableau Next migration runs one conversation at a time, and it never skips a step.
-
01
Ask in natural language
Name the workbooks or the project that should move, and the workspace they should land in.
-
02
Read the plan
Every item in order, data sources before the workbooks that use them, with what the grounding gate found spelled out.
-
03
Rehearse it
A dry run reads and converts everything exactly as the live run will, and writes nothing.
-
04
A person approves
A signed-in person types the approval phrase. No model or agent can start a live run.
-
05
Watch it land
Each item ends done, already there, skipped with the reason, or failed in Salesforce's own words.
Checked before it goes live.
Salesforce checks the agent before anything is saved, a person deploys it, and it never changes under your feet.
-
01
Validate
A check-only deploy: Salesforce checks the agent, its planner, its topics and its permission set, and saves nothing. Any error comes back in Salesforce's own words.
-
02
Deploy
A person types the deploy phrase. Deploying works only after a validation has passed, and it switches on the latest version.
-
03
Update
Salesforce never edits an active agent, so each update ships as the next version. The running one keeps answering until you switch the new one on.
A person always has the last word.
People approve every live run
No model, agent, token or integration can start one. A signed-in person types the approval phrase, after a plan and a dry run that writes nothing.
One refused sign-in stops everything
After a refusal, the layer asks for no new sign-in until a person clears the pause, so no retry loop can ever lock a Salesforce user out.
Secrets stay sealed
Credentials are sealed, shown only by their last four characters and never written to a log.
Honest outcomes
Every item ends done, already there, skipped with the reason, or failed in Salesforce's own words. Nothing is reported as done unless it is.
Answers it can prove.
Every answer comes from indexed documentation, and every answer shows where it came from. When the knowledge base doesn't cover a question, the agent doesn't guess. It tells you it will check with the team, and "I don't know" becomes a case.
Why did my extract refresh fail last night?
Checking your site and the knowledge base
- 1Refresh history on your siteLive, read-only
- 2Extract refresh failuresKnowledge base
- 3Refresh extracts on a scheduleTableau help
The Sales Weekly extract stopped at 2:10 AM because its saved database password changed1. Update the embedded credentials on the data source, then run the refresh again23.
Still stuck? Open a case with this conversation.
-
Indexed, never invented
Real documentation is split into passages and indexed in Postgres with pgvector. Only real, verifiable text goes in.
-
Sources on every answer
Each answer lists the documents it drew on, so you can read them for yourself.
-
Your documents too
Administrators can add their own Markdown or text documents and re-index the knowledge base in one click.
-
Tableau help, built in
How-to answers draw on about 3,000 pages of official Tableau help for Tableau Server and Tableau Cloud.
The rules it works by.
-
01
All or nothing
A dashboard is only rebuilt on the warehouse its data already lives in. If a single sheet can't be matched, nothing is published, and you get the reason.
-
02
Numbers first
Averages, distinct counts and medians stay exact under dashboard filters, and every result is checked against Tableau's answer.
-
03
Proven before it ships
Every query runs on Databricks or Snowflake before publishing, so nothing opens with a SQL error.
-
04
Your identity, your roles
SSO roles carry through to both warehouses, so people only see what they're allowed to see.
-
05
Read-only by default
It only writes when you ask, and it logs every write.
Which Tableau dashboard would you start with?
Start there. We'll put the layer over it and answer its questions in natural language, and if you ever want it on another platform too, every number is checked against Tableau first.