> ## 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.

# Create a view

> Save a SQL transformation over your data — visually, by hand, or with Summand's help.

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.

<Steps>
  <Step title="Open the Views page">
    Click **Views** in the sidebar, then **+ New view**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Define joins, filters, and projections">
    Drag join keys between datasets, filter rows with predicates, project the columns you want. The builder writes SQL underneath.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Path 2 — Hand-written SQL

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

<Steps>
  <Step title="Switch to Code mode">
    Click **Code** in the editor's mode toggle. The visual SQL is preserved as-is in the editor.
  </Step>

  <Step title="Edit freely">
    Standard ANSI SQL plus Athena extensions. Reference datasets by their Glue table name (visible in the schema panel).

    ```sql theme={null}
    SELECT
      o.customer_id,
      COUNT(*) AS orders,
      SUM(o.total) AS revenue
    FROM ${orders_glue_table} o
    JOIN ${customers_glue_table} c
      ON c.id = o.customer_id
    WHERE c.tier = 'enterprise'
      AND o.created_at >= DATE '2026-01-01'
    GROUP BY o.customer_id
    ```
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Path 3 — Have Summand draft it

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

<Steps>
  <Step title="Open chat with the dataset pinned">
    Make sure the dataset(s) you want to query are pinned to the conversation.
  </Step>

  <Step title="Ask for the view">
    *"Build me a view that counts orders per customer, grouped by tier, for orders since January 1."*
  </Step>

  <Step title="Review and save">
    Summand returns the proposed SQL inline. Click **Save as view**, give it a name, and it lands in your views list.
  </Step>
</Steps>

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](/concepts/experiments), 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.