Skip to main content
Views are saved SQL queries you can re-use across chat, experiments, and other views. Three ways to make one.

​
Path 1 — Visual builder

The default. Pick datasets and shape the query without writing SQL.
1

Open the Views page

Click Views in the sidebar, then + New view.
2

Pick base datasets

Add one or more datasets from your account. Cross-connector joins work — the curated Parquet for every connector lives in the same Glue catalog.
3

Define joins, filters, and projections

Drag join keys between datasets, filter rows with predicates, project the columns you want. The builder writes SQL underneath.
4

Watch the live Athena preview

The preview pane runs the SQL against the actual curated data and refreshes as you edit. If a query won’t compile, the error surfaces here.
5

Name and save

Give it a name (e.g. Active customers Q1) and a description. Save. The view is now addressable from chat and from experiments.

​
Path 2 — Hand-written SQL

Drop into the Code editor for anything the visual builder can’t express.
1

Switch to Code mode

Click Code in the editor’s mode toggle. The visual SQL is preserved as-is in the editor.
2

Edit freely

Standard ANSI SQL plus Athena extensions. Reference datasets by their Glue table name (visible in the schema panel).
3

Preview, name, save

Same as the visual path. Note that switching back to Visual mode discards hand-edits the builder can’t represent — the editor confirms before resetting.

​
Path 3 — Have Summand draft it

The lowest-friction path when you can describe what you want in English.
1

Open chat with the dataset pinned

Make sure the dataset(s) you want to query are pinned to the conversation.
2

Ask for the view

“Build me a view that counts orders per customer, grouped by tier, for orders since January 1.”
3

Review and save

Summand returns the proposed SQL inline. Click Save as view, give it a name, and it lands in your views list.
Views Summand creates inside a chat session start as chat views — pinned to the session, not addressable elsewhere. Saving promotes them to a regular catalog view.

​
Sharing a view

Views are owned by the user who created them. There’s no view-share model today — to give a teammate access to a view’s results, materialize it (run the SQL once and save as a separate dataset), or share the underlying datasets and let them rebuild the view themselves. View-level sharing is on the roadmap.

​
Using a view as an experiment source

When creating an experiment, pick View instead of Dataset as the source and select your view. The experiment’s components will run on the view’s output rather than the raw dataset. Useful for:
  • Defining a cohort once — “active enterprise customers in Q1” — and pointing several experiments at it.
  • Pre-aggregating — components run faster on a smaller, pre-aggregated view than on a raw 50M-row table.
  • Ensuring consistency — every experiment downstream sees exactly the same definition.

​
Limits

  • One SQL statement per view. Multi-statement scripts aren’t supported — chain via experiments instead.
  • Read-only. No INSERT / UPDATE / DELETE.
  • Glue-table references. Internal renames (display name changes) don’t break views; deletions do, with a clear error.