The Warehouse Builder in chat

The Warehouse Builder is a Mind that builds Warehouse objects for you in a chat: tables, columns, transformations and workflow runs. This page covers the Warehouse side of that chat, what the builder can create and change, and where the work continues; the Mind itself is on Warehouse Builder and Lake Builder, and the cards its steps show are on Warehouse tool cards in chat.

Ask the builder for a table

Describe what you want in your own words: the kind of table, its name and what it is for.
The builder works through the platform's own Warehouse tools, so the same rules apply as in the Warehouse screens, and it acts as you, with the permissions you hold (Warehouse permissions and row-level security).
Review the change. In Manual it waits on a card for your approval before anything is created (Change approval in a builder chat).
The new table arrives as a definition, not deployed. Deploy it when you are ready, either by asking the builder or from the table's Settings tab; until then, nothing is loaded into it and no preview is available (Deploy, run, truncate and monitor tables).

The builder creates all five table kinds:

Kind	What the builder sets up	Where the work continues
Fact	The table definition: its name, settings and columns	Create a dimension or fact table
Dimension	The definition: its name, history settings and columns	Create a dimension or fact table
Dictionary	The definition and its SQL queries, one per source system	Dictionaries
Static	The definition and its columns; you add the rows	Static tables
View	The definition and its query	Views

Two rules to know:

A table name cannot contain double quotes or backticks, and it is limited to 255 characters. A very long name can be refused earlier with The max name length is 211, current length is N.
Partitioning is set with a frequency: day, hour, halfHour, fifteenMinutes or year. A monthly frequency is refused; the builder tells you to use day and map the date as toStartOfMonth(<date>) AS "Snapshot Day".

The same chat also creates the semantic sources, source systems and logical models that group your tables; their naming and deletion rules are on Semantic sources, source systems and logical models.

Add or change columns in one batch

The builder adds and updates user columns in one batch, so a set of column changes arrives as one card and one change.
On a table that is already deployed, the change is applied to the deployed table directly.
Deletions are the careful part: system columns and locked columns cannot be deleted, and neither can a column that a transformation still uses. The card says why, and the full rules are on Define table columns.
Hand it a SELECT and it can propose the columns the query would produce. The proposal reads no rows and saves nothing; the flow is on Import columns from SQL.

Fill rows in Static and Dictionary tables

The builder can add rows to a deployed Static or Dictionary table, at most 1000 rows per call.
Every Static row must carry its primary-key columns. Every Dictionary row must carry a "Source ID" and a "Source System ID" that matches one of the dictionary's query source systems.
A removed row is not erased: it is marked with "Delete Flag" set to 1 and stays in the table, the same soft delete the Data Mapping grids use (Static tables, Dictionaries).
Purging the flagged rows removes them for good. That step is destructive, the card warns that the marked rows are removed permanently, and it cannot be undone.

Build a transformation from chat

The builder creates a transformation for a Dimension or Fact table, for one source system, and writes its SELECT query. The query is validated before anything is saved.
Scheduling stays manual: a new transformation arrives with its schedule off, and a person turns the schedule on in the Warehouse screens.
The pattern, name, table and source system are fixed when the transformation is created. The builder cannot change them later; it tells you to create a new transformation instead.
Saving a new query version un-finalizes the transformation: re-map if the columns changed, then test and finalize again.
A test run writes to its own scratch copies and never to the real table. When the test finishes, a review of the results comes first, and only then can the builder finalize.
After finalizing, the builder can run a full load or backfill a periodic transformation. The step pages are Build, test and finalize a transformation and Transformation patterns and load settings.

Start and resume workflow runs

The builder starts a manual run of a Warehouse workflow. A run starts only when no run of that workflow is live; while one is Running or Running Error, the start is Blocked, and the reason names the live run.
A run follows the workflow plan: the finalized transformations in dependency order. A transformation whose schedule is off is planned but skipped in the run, so enable the ones a run should load.
Stopping the wait is not stopping the run. If you stop a wait from the chat, the run keeps going on the server, and its result still arrives when it finishes (Stop and abort runs in chat).
Stopping the run itself is destructive. It ends the run where it is; the warning says the interrupted load is not rolled back. What finished stays, and a restart resumes the run later (Monitor and fix a run).
A failed or aborted run resumes in place: ask the builder to restart it, and only the unfinished work runs again, with the finished steps kept.

Where the work continues

Most builder work hands off to the Warehouse screens. The builder also reads as it works: health checks, partitions, query plans and change history appear as cards (Warehouse tool cards in chat).

What you want next	Where to do it
Create more objects by hand	Create Warehouse objects
Deploy a table, run or abort a transformation, truncate, drop or delete	Deploy, run, truncate and monitor tables
Work on a Fact or Dimension: history, partitions, permission groups	Create a dimension or fact table, Dimension and fact general settings
Change columns on an existing table	Define table columns
Finish a Dictionary's queries or rows	Dictionaries
Edit Static rows, upload Excel or fill with AI	Static tables
Finish a View's query, columns, dependencies or refresh	Views
Test, finalize or schedule a transformation	Build, test and finalize a transformation, Transformation patterns and load settings
Group tables with semantic sources, source systems and logical models	Semantic sources, source systems and logical models, Logical models
Change many tables at once	Batch edit
Check who can read a table, and limit rows	Warehouse permissions and row-level security
Preview rows	Preview table data
See what uses a table before deleting it	Dependencies and dependants
Design a semantic model from the same chat	Design a model with the Warehouse Builder
Turn workflow schedules and workflows on or off	Schedules and when a workflow starts, The Workflows screen
Read the message you got in chat	Troubleshooting

Questions, answered

Does the builder deploy the tables it creates?

A new table arrives as a definition, not deployed. Ask the builder to deploy it, or deploy it yourself from the table's Settings tab. A deploy is a change like any other, so the chat's acceptance mode decides whether it waits for your approval. Until a deploy runs, the table cannot be loaded or previewed (Deploy, run, truncate and monitor tables).

Why did the builder refuse a monthly partition?

A table partitions by day, hour, halfHour, fifteenMinutes or year, not by month. The refusal tells you to use day and map the date in the transformation with toStartOfMonth(<date>) AS "Snapshot Day".

Can the builder change the columns of a deployed table?

Yes. It adds and updates user columns in one batch, and on a deployed table the change is applied to the deployed table directly. Deletions are refused for system columns, locked columns and any column that a transformation still uses; the details are on Define table columns.

Can the builder change a table that already exists?

Yes, within the same Warehouse tools. For an existing table it can change the comment, logical models, source systems and history or retention settings, and for a view the query or refresh schedule. Some fundamentals cannot be changed: a table's name, label, kind, partition frequency and permission groups.

How many rows can the builder add to a Static or Dictionary table at once?

At most 1000 rows per call, into a deployed table. Every Static row must carry its primary-key columns; every Dictionary row must carry a "Source ID" and a "Source System ID" that matches one of the dictionary's query source systems. A bigger set takes several calls.

What does "Delete Flag" mean when the builder removes a row?

A removed row is not erased: it is marked with "Delete Flag" set to 1 and stays in the table. Purging the flagged rows removes them permanently; that step is destructive, so the card warns first, and it cannot be undone.

Why can't the builder start a workflow run right now?

Because a run of that workflow is already live. A manual run starts only when nothing is Running or Running Error; while one is, the start is Blocked, and the reason names the live run. Wait for it to finish, or stop it, and then ask again (Stop and abort runs in chat).

When the builder stops a workflow run, is the load rolled back?

No. Stopping ends the run where it is, and its unfinished work is not rolled back by the platform. What finished stays, and a restart resumes the run later (Monitor and fix a run).

After a workflow run fails, can the builder restart it?

Yes. It can resume a failed or aborted run in place: the same run continues, keeping its finished steps, so only the unfinished work runs again. Fix the cause first. A restart is also available from the run's window on the Workflows screen (Monitor and fix a run).