A Warehouse Builder chat can design a DataPrism semantic model from your Warehouse objects: the builder proposes one design, you approve it, and an empty model is created for its Model AI to build. This page covers the Warehouse side of that flow: what a design may hand over, the checks that must pass before the model is created, and what happens after it is handed over. The journey from asking to approving is on Design a model with the Warehouse Builder, the card is on The semantic model design card, and the access check and handoff are on Access checks and Model AI handoff.
Ask the builder for a model
Open a chat with the Warehouse Builder Mind and describe the model you want, or type /star-schema to load the Star schema skill (Warehouse Builder and Lake Builder). The builder asks what it needs in one batch of questions.
It proposes one card, Semantic model design, with the ER diagram, your choices and the rest of the design; every section is described on The semantic model design card.
Decide the card: set the choices and approve, or reject with a note so the builder proposes a corrected design.
On approval, the builder builds the approved objects, proves them, and runs the readiness checks below. The model is created only when every check passes.
The model is created empty, and the builder hands the build brief to the model's Model AI, which fills it.
What a design may hand over
One fact source: the fact table itself, or one handover view of it, never both. The rest of the design hands over the dimensions the fact joins to and the helper views it lists.
A handed-over view reads at most 20 objects of the design, and the model reads only what the design hands over.
Each object is marked as new, existing or changed. New objects are built by the builder; an object marked as new that already exists in the Warehouse is refused, because the platform does not adopt a table that this conversation did not create.
Two objects cannot share a name, and two handed-over objects cannot both use one business column name: Two group-bys of one name fail: prefix them.
The limits on one design
Objects: 1 to 60, each with 1 to 200 columns.
Relationships: up to 60, each going from the fact source to a handed-over dimension.
Charts: up to 20, with up to 3 history options to choose from and up to 10 items under What this model cannot serve.
A design that outgrows its size budget is refused with the limit named; the builder shortens it or splits the model.
The single consent card
The card is the only consent for the build. Nothing is built from the design until you approve it, and the card asks in every acceptance mode.
The card arrives on its own, and the chat resumes when you decide.
When you approve, the platform re-checks the design and your choices before it records the session. If a check fails, the card says the design no longer passes its checks and asks you to reject it with a note so the Warehouse Builder proposes it again.
Note
The design card is consent, so no mode skips it. A chat set to apply changes automatically still stops for this card.
Before the model is created
The model is created only when all four checks pass. In order:
Every approved object is built and deployed. A missing object is refused with "X" is not built yet. Build every approved object first.; an object that exists but is not deployed is refused with is not deployed. Deploy it, and the builder tries again once it is deployed. Deploy the table from its Settings tab (Deploy, run, truncate and monitor tables).
The owner role reaches every object. For a business role, a missing grant brings the Grant role access card, and you add the role under Permission Groups on each object (Warehouse permissions and row-level security; the card flow is on Access checks and Model AI handoff). The admin role reaches every object without a grant, but an admin-owned design hands over views only: Owner role admin needs views over every handed-over table.
Row-level security is acknowledged. If a handed-over object reads a table whose row-level security the model does not apply, tick I understand on the card. A warning that the card could not show sends the design back for a new proposal.
Personal data is marked. A handed-over view that projects personal data must carry its mark before the model can be created: the builder reports that the column carries no PII mark, so every report on this model would show it in clear, marks it after you ask in the same chat, and the check re-runs.
Create the model
Only the person who asked for the design can create it: if someone else tries, the answer is only name, who asked for this model, can create it. Ask them to continue this conversation.
The model is created empty, in the requester's personal workspace, with the approved owner role and data mode. It opens from the created card; the model itself is Semantic models and BI tables.
Creating is idempotent: one design creates one model. If a first attempt was interrupted, asking again finds this model by its session key and records it, it never creates a second one; while a creation is in flight the answer is the model of this session is being created, and a reply that DataPrism did not answer just needs another try in a minute.
If the model is deleted after creation, the session stops: the model of this session was deleted; propose the design again to start over. A newer approved design replaces an older one, and only the newest creates.
Hand over to Model AI
The builder adds no tables itself: the model is created empty, and the brief says which tables to add.
From the created card, Send the brief to Model AI hands the build brief to the model's Model AI, which builds the model's tables and relationships; the model opens in DataPrism (Model Builder, Model AI).
From then on, changes to the model are decided in the model's own chat, by the person who asked or another editor of that model: while a change waits, the chat says This change has NOT been made., and a rejection reads An editor of this model rejected this change, so it was NOT made.
Questions, answered
What does a design hand over to a model?
The objects the model reads: one fact source (the fact table or a single handover view of it), the dimensions the fact joins to, and the helper views the design lists. A handed-over view reads up to 20 objects of the design, and the model reads nothing else.
How many objects can one design hold?
1 to 60 objects, each with 1 to 200 columns, plus up to 60 relationships, up to 20 charts and up to 3 history options. A design that grows past its size budget is refused with the limit named; the builder shortens it or splits the model.
Why must the fact be handed over only once?
A semantic model has exactly one fact table, so the design hands over either the fact table itself or one handover view of it. Handing over both is refused: "X" and its handover view "Y" are both handed over: hand over only the view. A design that does not hold exactly one fact object is refused before it reaches you.
What happens if an approved object is not deployed yet?
The model is created only after every approved object is built and deployed. If an object is missing, the builder refuses with "X" is not built yet. Build every approved object first.; if it exists but is not deployed, it refuses with is not deployed. Deploy it, then runs the check again once you deploy it. Deploy the table from its Settings tab (Deploy, run, truncate and monitor tables).
Who can create the model from a design?
Only the person who asked for the design: only name, who asked for this model, can create it. Ask them to continue this conversation. Creating also needs the Add DataPrism Semantic Model permission.
Can one design create more than one model?
No. One design creates one model, and a retry adopts the model it already made: it finds this model by its session key and records it, it never creates a second one. If the first try could not record the model, ask again after two minutes.
What if the model is deleted or the design is replaced?
If the model is deleted, the design session stops: the model of this session was deleted; propose the design again to start over. If the design was approved again later, the older session was replaced by a newer approved design, and only the newest one creates the model.
Who approves changes to a model after it exists?
The change waits in the model's own chat and resumes when the person who asked or another editor of that model decides it. While it waits, the chat says This change has NOT been made., and a rejection reads An editor of this model rejected this change, so it was NOT made. (Model AI).
Why does the design no longer pass its checks?
The platform re-checks a design when you approve it, so something that was fine earlier can fail later. One common case: an object marked as new whose table already exists in the Warehouse but was not created in this conversation; the refusal asks you to reject the card with a note so the Warehouse Builder marks it as existing or changed. Reject with a note whenever the card says the design no longer passes its checks, and the builder proposes a corrected design.