Use a view to expose shaped Warehouse data to queries and reports. A view is defined by a query. It can store no data at all, or store its rows and refresh them on a schedule you set.
| View type | Stores data | Refreshes | Parameters | Needs a primary key to deploy |
|---|---|---|---|---|
| Standard | No | Runs on demand | None | No |
| Parametrized | No | Runs on demand | You can add your own | No |
| Refreshing | Yes | On the Refresh Interval you set | None | Yes |
| Appending | Yes | On the Refresh Interval you set | One required parameter, set from Incremental Days | Yes |
Standard and Parametrized views store no data, so there is nothing to refresh, truncate or drop. Use a transformation instead when you need rows loaded into a Dimension or Fact table on a schedule.
The view opens in its own popup with four tabs: View, Preview, Dependants and Settings. Settings appears only for Refreshing and Appending views. The View tab holds the five-step wizard: General, Query, Columns, Dependencies and RLS. A step bar above the form shows where you are.
Click Finish on the last step, then deploy the view. Until it is deployed, the view shows Pending in the tree.
View Name is required, and it is locked once the view exists: a view cannot be renamed.
View Type starts on Standard. While you edit an existing view, changing the type shows the warning "Changing view type will result in data loss in next steps." in the strip above the form; Dismiss warning clears it.
Incremental Days appears for Appending views only. It is the whole number sent to the view's required parameter: 0 to 9999, default 1.
Logical Models takes at least one model, up to 20. Permission Groups sets which roles can read the view; the admin group is always included and is not listed in the picker.
Refresh Settings appears for Refreshing and Appending views:
| Setting | What it does | Default |
|---|---|---|
| Refresh Interval | How many units pass between refreshes. A whole number, 1 or more. | 1 |
| Refresh Interval Unit | Minute, Hour, Day, Week or Month. | Hour |
| Refresh Offset | An optional offset, set together with Offset Unit. Choosing None as the unit clears both halves. | Empty |
| Offset Unit | The unit of Refresh Offset. | Empty |
| Retries | How many times a failed refresh is retried. Enter -1 to retry without a limit. | Default (2) |
Query Execution Settings also appears for Refreshing and Appending views. The tile starts on Eco (default); Configure opens the three presets. Balanced balances speed and memory, Turbo runs faster and uses more RAM, Eco saves RAM and runs slower. The preset is applied to the view when it is deployed.
The first save of General creates the view: the toast reads "General settings created successfully." Later saves read "General settings updated successfully."
A step must pass its checks before it saves or lets you move on. A failed check shows a Validation Error toast, and the message names the field it belongs to. On General the messages read:
When you validate the query, the server refuses with:
A banner above the form reads "View needs to be deployed to be used in the warehouse" with a Deploy button. It appears once the view has a saved record and a query, and hides after the view is deployed. You can also deploy from the view's right-click menu in the tree: Right-click menus.
Two rules guard the deploy:
The result shows one of three toasts: View deployed successfully, View partially deployed (some objects failed; the description names the first failure) or View deployment failed.
For the full list, see Warehouse permissions and row-level security.
Refreshing and Appending store their rows and refresh them on the Refresh Interval you set. Standard and Parametrized run their query on demand and store nothing.
The Settings tab appears only for Refreshing and Appending views. Standard and Parametrized views store no data, so there are no statistics, refresh schedule or stored data to manage.
Two checks stand in the way. The query must be validated first; otherwise the deploy is refused with "Query must be validated before creating view". A Refreshing or Appending view also needs a PK column; until one is marked and applied, the banner points you to Columns instead of offering Deploy.
View Name is locked once the view exists. Create a new view if you need a different name.
It sets the value of the required parameter in an Appending view. The Query step shows that parameter, and your query must use it; see Write and validate a View query.
The type drives what the later steps set up, from refresh schedules to key flags. Changing it on an existing view can lose that setup, so the editor shows "Changing view type will result in data loss in next steps." Review the following steps again after you apply the change.
Not silently. When the current step has unsaved changes, Next and Finish ask the Unsaved Changes question first, and you choose whether to save your changes and continue or discard them and continue. Apply saves the step without leaving it.
Yes, for Refreshing and Appending views. Query Execution Settings on General starts on Eco (default); Configure switches between Balanced, Turbo and Eco.
No. The server refuses PII on view tables with "PII cannot be enabled on view tables". A view column can instead point at a source column that has PII enabled, through its PII Source setting on View columns.
The bar shows your place in the wizard: steps you finished are marked as done, the current step signals an error or unsaved changes, and steps you have not reached stay dim.