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:
- Default project home, the built-in view every Project has.
- Every custom view the Project has authored, in path order.
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.
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.htmlNesting 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 |
| 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 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, or open a data source. 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 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.