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 are what the sidebar offers in Operate. Switch a Project to Operate and 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 that opens when someone arrives at the Project. If the view named as Home is deleted, the Project falls back to the built-in default rather than opening nothing.
In Build, the same views are listed under Automations in the Context tree, alongside Workflows. Automations is what the Project runs and shows; the rest of the tree is what it is made of.
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 in Build
Switch the header to Build so the Context tree is showing.
Ask for it in chat
Find Custom views under Automations and use Create a custom view in chat. The composer opens seeded with "Create a custom view for this project that ", and you finish the sentence:
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 the view's row menu in the Context tree. 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, 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.
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. Anyone who can open the Project can switch to Build and see the whole Context tree. Use teams and permissions to control access to data, and views to control what is convenient.