Building Models
Use the Agent to design, validate, and save Data Studio models while keeping inputs, outputs, assumptions, and failure behavior explicit.
Last reviewed July 13, 2026
The Agent can help create supported Data Studio models from a business requirement. Use it to inspect inputs, draft logic, preview results, and save a durable model—not to skip validation.
Before you start
- Identify the business outcome and expected output grain.
- Choose the source tables and stable join keys.
- Decide whether SQL, Python, a notebook, grouping rules, or another supported model type is appropriate.
- Define the output table or reusable property and how downstream consumers will use it.
Build a model
- Ask the Agent to inspect candidate inputs and schemas.
- Confirm the selected fields, grain, timezone, and identity keys.
- Describe the calculation and edge cases in business terms.
- Ask for a preview on a small, representative sample.
- Compare the preview with hand-checked examples.
- Review the generated code, configuration, and output schema.
- Save the model only after the preview and assumptions are correct.
- Run it and confirm the materialized output in Activity Logs and the warehouse.
Prompt example
Build a customer-level SQL model with one row per customer. Calculate completed-order revenue, refund value, order count, first order date, and most recent order date in the workspace timezone. Exclude test orders and show five hand-checkable customers before saving.
Validate the output
| Check | Question |
|---|---|
| Grain | Is there exactly one row per intended entity? |
| Keys | Are IDs stable, non-null, and unique where required? |
| Time | Are timezone and date-window boundaries explicit? |
| Money | Are currency, tax, discounts, and refunds treated consistently? |
| Nulls | Does missing data produce the intended fallback? |
| Reruns | Is replace, append, or merge behavior safe? |
| Consumers | Will reports, audiences, or destinations read the expected schema? |
Edit and rerun
When a preview fails, ask the Agent to explain the first root error before changing code. Fix one cause at a time, rerun the smallest useful sample, and recheck the output contract after every schema change.