Custom views

A custom view is a page your Project draws for the people who operate it. Instead of sending a business user into the Context tree to find what they need, you give them the one screen that answers their question.

Audience: builders

Where views show up

Views have their own rail in the sidebar, and everyone who can open the Project sees it. See Who sees what. The Views rail lists:

Pinned, at the top: the Home view, the built-in default view, and the views you pin. It holds at most five rows.
Your folders, each with the views you moved into it.
Unfiled views, where every new view appears until you move it.

One view can be marked Home. It carries a Home badge in the rail and is the view a member opens on when they arrive at the Project. If the view named as Home is deleted, the Project falls back to the built-in default rather than opening nothing.

All views and descriptions, at the bottom of the rail, opens a directory of every view. Search names and descriptions, filter by folder or pinned, and see who last edited each view and how often it was opened in the last 30 days.

Organize views

Builders and admins organize the Views rail for everyone on the Project. Members see the same layout and cannot change it.

Pin a view. Point at the view's row and use its pin button, or use Pin to top in its row menu. Use Unpin to take it back out.
Reorder the Pinned group. Drag a view anywhere in Pinned, including above Home or the built-in default view. The default view can also be unpinned and moved into a folder; when it is unpinned, it appears in Unfiled. It cannot be renamed or deleted.
Group views in folders. Use New folder, then drag a view into it or use Move to folder… in its row menu. Rename folder… and Delete folder… are on the folder's menu.
Name and describe a view. Use Rename… to give the view a display name, and Edit description… to say what it is for. Pointing at a row also shows an edit description button. The description shows in the Views rail, when you point at a view's name, and in the directory.

Renaming a view here changes only how it is listed. Its HTML file, its links, and its saved state stay as they were, and so does moving it to a folder. The layout, names, and descriptions are stored in views/views.json in the Project's file tree. If two builders change the layout at the same time, the second save shows an error with a retry instead of overwriting the first.

Because the Views rail lists them, the Context tree does not list the views a second time. Workflows stay under Automations in the Context tree.

How a view is stored

A custom view is a single HTML file under views/ in the Project's file tree:

views/vendor-inbox.html
views/close-status.html
views/exceptions/aging.html

Nesting is allowed. The file must end in .html and must sit under views/: anything else is not treated as a view. Because views are ordinary Project files, they are versioned with the rest of the Project and travel with it.

Create a view

Open the Project as a builder

Creating and changing views needs Builder access to the Project.

Ask for it in chat

Describe the view in the Project's conversation:

Create a custom view for this project that lists open vendor inquiries, grouped by age, with the invoice number and the amount, and a button to open each one.

Review the change

The agent writes the HTML and comes back with a change for you to review. Nothing lands in the Project until you apply it.

Mark it Home if it is the main screen

Use Make project home in the view's row menu in the Views rail. The badge moves to the view you pick.

You can also just add the file. Views are plain HTML in the Project file tree. If you would rather write or paste one yourself, add it under views/ and it appears in the rail.

What a view can read and do

A view runs in a frame with a runtime that lets it read the Project it belongs to and act on it. It is not a static page, and it is not an arbitrary web app: it can reach the Project and nothing else.

A view can read:

Area	What it can ask for
Project	The Project it is running in, and who is viewing it
Work items	List, query, and read Work items and their outputs, and a Work item's model usage: tokens and estimated cost in total, by model, and by purpose
Model usage	The Project's model usage over a time range: tokens and estimated cost, grouped by Workflow, Work item, step, model, or purpose, and by day, week, or month
Workflows	The Project's Workflows and their triggers
Files	List files, read JSON, download
Data	The Project's attached data sources
Verified logic	List approved logic, read one, start a run
State	Store and read small amounts of its own view state

A view can also save a reader's preferences, such as filters or the selected tab, with the standard localStorage methods (getItem, setItem, removeItem, clear). Values are kept per reader, Project, and view in the reader's browser, and are loaded before the view's scripts run. The view decides what it saves; nothing is captured automatically.

A view can also ask the platform to do things on the reader's behalf: open a Work item, start a conversation about a Work item, rerun a Work item, archive or restore Work items, run a Workflow, create a Work item, open a data source, or open a Project file in the app's file preview. These arrive as requests to the host, which means the platform applies the reader's permissions to them. A view cannot do anything the person reading it could not do.

Rerun and archive change data, so a view offers them only when the person reading it has permission to operate the Project's Work items. A rerun starts a new run of the Work item on the latest version of its Workflow, from its stored inputs. Archive takes 1 to 20 Work items at a time and stops at the first one that fails.

A view can also work with the decisions waiting in the Project. It can list them, oldest first if it asks, and read each one's question and options. It can answer a decision, or open the same decision card the Work item shows, in a dialog over the view. Answering follows the same rules as answering in the Work item: only people who can operate the Project can answer, the platform checks every answer, and a decision someone else answered first is not answered again. A view cannot answer decisions in a preview.

A view reloads when the files it reads change. If a run writes the JSON or CSV behind a view while you are looking at it, the view picks up the new data in place instead of showing what was there when you opened it.

Views follow the platform's light and dark theme.

A view is a lens, not a boundary. Leaving something off a custom view does not hide it. Use teams and permissions to control access to data, and views to control what is convenient.

Bound email Data