Views

A View is a reusable, queryable definition over the data model - a dataset (a table of rows) or a single scalar value. Views power lists, reports, lookups (as a Lookup Field Type target), and can be called directly as SQL functions from elsewhere in the platform - entity expressions, other views, Server Functions.

Every view can be built two ways, and you can switch between them at will:

Design mode - a visual canvas: add sources, join or union them, pick output columns, all without writing SQL.
AI/Code mode - an AI-first interface where you describe what the view should do and let the assistant write or explain the SQL, with a direct SQL editor available when you need it.

The Views screen

Navigate to Data Explorer → Views to see all views in the current application, listed with:

Column	Description
View Name	Human-readable name
Result Type	Dataset (a table of rows) or Scalar value (a single value)
Definition Type	Design or AI/Code - which mode the view is currently defined in
Module Name	Which module the view belongs to
Created By	The user who created it
Modified On	Last modification timestamp
Published On	When the view was last published
Status	A checkmark (✓) if published and current, or a Publish link if there are unpublished changes

Use + Add View to create a new one, and the row checkboxes plus Delete to remove views in bulk.

Choosing a Result Type:

Result Type	Returns	Typically used for
Dataset	A table of rows	List screens, reports, a Lookup Field Type’s Target Type, a join source for another view
Scalar value	A single value	An Expression default value or a Stored/Virtual Calculation that needs logic too complex for a plain SQL expression - once published, a Scalar value view shows up directly in the Scalar SQL functions Palette catalog

A published Dataset view behaves the same way: it appears in the Dataset SQL functions catalog, callable as a set-returning function from other views.

View detail view

Click a view to open the Edit View panel - Open (slide-in) or Open in Tab (full page), the same pattern as entities and structures. Publish sits top-left, Clone top-right, and Open / Open in Tab at the bottom.

Two tabs sit below the header: Details, and either AI/Code or Diagram depending on which mode the view is currently in. A toggle - “View is in Code Mode / Set Design Mode” (or the reverse) - switches between the two at any time. A Preview button (top right of the editor) lets you run the view and see results without leaving the panel.

Both modes share three underlying concepts:

Sources - the entities, components, views, or inline queries the view reads from.
Input Params - parameters the view accepts when run (used to filter, or passed into the SQL).
Output columns - what the view actually returns, configured per-source and globally via Main.

AI/Code mode

The AI/Code tab opens in AI chat view by default - a conversation panel where you can ask the assistant to explain the current query, generate SQL from a description, or rewrite it on request. This is the primary interface: the AI can write the entire query for you, starting from a plain-language description of what the view should return. A Send on Enter toggle controls whether Enter submits the message.

See Code / Use AI toggle: a button in the top right switches between the AI chat and the SQL editor. Click See Code to open the editor and inspect or directly edit the generated SQL; click Use AI to return to the chat. The toolbar in the SQL editor - Sources, Input Params, Palette, and an expand icon - is available when in code view.

Sources

Click Sources to see the sources currently added to the query, each shown as an expandable row (revealing its columns) with a + Add button to add another.

Adding a source opens the Add Source panel:

Field	Description
Source Type	Entity, Component, View, or Query (an inline subquery)
Entity / Component / View	The specific target, for the first three source types
Source Name	The alias used to refer to this source in the SQL - auto-generated, editable
Status Filter	Live or latest instances, or All statuses
Exclude Deleted Records	Checkbox, on by default

Once added, a source’s alias is available directly in the SQL - e.g. an entity_build_settings source becomes ebs in a query, referenced as ebs.value, ebs.entity, and so on.

The Status Filter is what makes a view aware of the record lifecycle (Draft → Submitted → Live → History → Deleted) rather than just reading every row in the table. Live or latest instances - the default - returns only the current version of each record, which is what almost every list, report, or lookup should be built on. All statuses includes every historical version too, which matters for audit-style views but would otherwise produce duplicate-looking rows for any record that’s been resubmitted more than once. Exclude Deleted Records filters out soft-deleted records on top of whichever Status Filter is chosen.

Input Params

Click Input Params to see the parameters the view accepts, listed by Parameter Name and Parameter type. + Add opens a form:

Field	Description
Parameter Name	Human-readable name
Parameter ID	Auto-generated from the name
Parameter Type	Any base type, or an entity/lookup type (e.g. “Organization (Core)“)
Parameter Description	Free text
Required	Checkbox
Value Type	Value (a fixed default) or Expression (a default computed by a SQL expression, defaulting to `null`)

Input params are referenced in SQL with {{param_id}} placeholder syntax - e.g. ON ebs.entity = {{thing_id}}.

Palette

The Palette is a command launcher inside the editor (also reachable while typing) offering several searchable catalogs:

Sources Catalog - search added sources, down to individual columns (e.g. entity_build_settings.value), and insert a reference at the cursor.
Input Parameters Catalog - search the view’s input params and insert a reference.
Scalar SQL functions / Dataset SQL functions Catalogs - functions built in Anybuild itself (i.e. other views with Result Type Scalar value / Dataset, exposed as callable functions), grouped by the application they belong to and shown with their fully-qualified name, e.g. core.bu_function, contract_news.get_organisation_id. See Applications → Application settings for how an application’s ID becomes its SQL schema name.
Postgres Functions Catalog - the built-in PostgreSQL function library.
Snippets Catalog - reusable SQL snippets.

Selecting a function from one of the function catalogs inserts a call into the editor with a typed placeholder for every parameter, e.g.:

core.business_unit_function(<business_unit onedb_data_layer.lookup_field>, <on_date timestamptz>)

You then replace each <name type> placeholder with a real value or expression.

Main - output columns

Click Main to open Query Details → Columns: the list of columns the query actually produces (their generated key and a type badge, e.g. list_ui_settings / JSON). This is where you set the display column name - what end users see as a list header - and override the Field Type, which controls display formatting (marking a column as a Date field type applies date formatting even if the underlying SQL value is a timestamp).

Preview

Preview opens a modal with a generated form for the view’s input params - a search-and-add picker for entity-typed params, a plain input for scalar types - plus a <> JSON toggle to switch to raw JSON input instead. Run executes the view with the supplied parameters.

Design mode

The Diagram tab is a visual canvas, with the same pan/zoom/fit/grid controls as the entity diagram view. Sources appear as cards - a header bar showing the source type (e.g. ↗ ENTITY), its name, a + and a ⚙ - with their fields listed beneath. Checkmarks next to fields show which ones are currently in the output.

Adding columns to the output

Click a field directly on a source card to toggle it into the view’s output columns.

Each source card’s + adds another source, related to it - either by Union (stacking another source’s rows into the same result) or Join, depending on the view’s overall combination mode (Join is the default).

Two shortcuts skip manual join configuration entirely:

Clicking the small + next to a Reference field on a card adds the referenced entity as a new joined source automatically (Left Join by default), with the join condition inferred from the reference.
In the New Relation drawer (opened from a card’s +), choosing Child Component as the Source Type only asks for the Child Component Field - the join back to the parent is resolved automatically.

For every other Source Type - Entity, Component, View, Query - the New Relation drawer needs full manual configuration:

Field	Description
Relationship Type	Left Join, Inner Join, Right Join, or Cross Join
Source Type	Reference, Child Component, Entity, Component, View, or Query
Target picker / Source Name / Status Filter / Exclude Deleted Records	Same fields as the Code mode Add Source panel
Join Condition	One or more rows, added with + Add New Field: a From field, a Mapping Type (Maps To another field, or Has Value a fixed value), and a To field or value

Per-source columns, filter, and order

Click a source card’s ⚙ to open a drawer scoped to that source, with three tabs:

Columns - the columns selected from this source, each with a reorder handle, Column Name, a Field Type badge, an expression indicator, and delete. + Add adds a new column.
Filter - filter conditions applied to this source specifically, before it’s combined with others.
Order - sort order applied to this source specifically.

Adding or editing a column opens an editor with Column Name, Column ID, Field Type, and a SQL expression box - with the same Sources / Input Params / Palette helpers available in Code mode. This means a column doesn’t have to be a plain passthrough of a source field: it can be any SQL expression, scoped to that one source, using scalar functions just like in Code mode.

Main - the global output

Click Main to see the same Columns / Filter / Order tabs, but applied globally - across the full combined (joined/unioned) result, rather than one source. This is the equivalent of the Code mode Main panel, just operating on the visual result instead of raw SQL.

Worked example

Say you want a view that lists open invoices together with the customer name and account manager from the related Customer record - data that lives across two entities.

Invoice is added as the root source. Its fields (Invoice Number, Due Date, Total, Status, and so on) appear on the card.
Clicking + on the Invoice card opens New Relation. Because Invoice has a Reference field pointing to Customer, clicking the small + next to that reference field adds Customer as a joined source automatically - no manual join condition needed.
Back on the canvas, the two cards are connected with a “Left Join” edge. Click the fields you want in the output - Invoice Number, Due Date, Total on the left card, Customer Name and Account Manager on the right - to add them to the result.
Clicking Main shows all selected columns together, where they can be renamed and given display Field Types before publishing.

The same result in AI/Code mode would be a SELECT ... FROM invoice inv LEFT JOIN customer cust ON inv.customer = cust.thing_id query - Design mode is constructing that join for you, inferred directly from the reference field.

Choosing between modes

Design mode covers most cases - entity/component sources, standard joins via references and child components, simple filters and column selection - without writing SQL. AI/Code mode is there for anything Design mode can’t express: complex CTEs, window functions, conditional logic, or calling other Anybuild-defined functions directly. Start by describing what you want in the AI chat, switch to the code editor to review or tweak the result, and switch back to AI at any point. Because both modes operate on the same underlying view definition, switching between them is just a toggle - there’s no need to commit to one approach for the life of a view.

Where views go from here

A view is rarely the end of the line - it’s almost always feeding into something else:

As a Lookup Field Type target, a Dataset view controls exactly what a Reference field’s search dialog shows and searches.
As a Scalar value view, it can back an Expression default value or a Stored/Virtual Calculation whenever the logic needed is more than a one-line SQL expression.
Published views - Dataset or Scalar - become callable functions for every other view, exactly the way Postgres’s own built-in functions are, via the Palette’s function catalogs.
Database Workflows and Server Functions can call published views the same way, making a view a reusable unit of query logic shared across the whole application rather than something rewritten per consumer.