Views are saved SQL queries you can re-use across chat, experiments, and other views. Three ways to make one.Documentation Index
Fetch the complete documentation index at: https://docs.summand.com/llms.txt
Use this file to discover all available pages before exploring further.
Path 1 — Visual builder
The default. Pick datasets and shape the query without writing SQL.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.
Define joins, filters, and projections
Drag join keys between datasets, filter rows with predicates, project the columns you want. The builder writes SQL underneath.
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.
Path 2 — Hand-written SQL
Drop into the Code editor for anything the visual builder can’t express.Switch to Code mode
Click Code in the editor’s mode toggle. The visual SQL is preserved as-is in the editor.
Edit freely
Standard ANSI SQL plus Athena extensions. Reference datasets by their Glue table name (visible in the schema panel).
Path 3 — Have Summand draft it
The lowest-friction path when you can describe what you want in English.Open chat with the dataset pinned
Make sure the dataset(s) you want to query are pinned to the conversation.
Ask for the view
“Build me a view that counts orders per customer, grouped by tier, for orders since January 1.”
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.