Everyday work
Working a Project from a business user's seat. Ask it for help, review what it produced, correct what is wrong, and watch it get better from your input. You stay in control.
Audience: business users
Operate is where you work
A Project has two lenses, and yours is Operate. Build is for changing what the Project is made of; Operate is for working it. Switch between them from the header. See Operate and Build.
- The Operate and Build switch. Operate is the lens that shows what the Project produces rather than what it is made of.
- Two rails: Views and Work items. Everything you do here starts from one of them. Views are the screens the Project draws for you. Work items are the things waiting for your judgment.
- The views this Project has. One can be marked as the project home, and that is the one that opens when you arrive.
- The view itself, rendering in the workspace.
Views: the screens built for you
A view is a page the Project draws for the people who operate it. Rather than sending you hunting through everything the Project contains, it puts the answer to your question on one screen.
Every Project has a Default view. Beyond that, a builder can author custom views shaped around your work: an inbox for a particular Workflow, a status board for the close, the exceptions that need chasing today.
Views are live, not screenshots. They read the Project as it stands right now, and they can act: open a work item, start a conversation about one, or kick off a Workflow run. A view can never do something you could not do yourself, because your permissions still apply.
A view is a lens, not a boundary. Leaving something off a view does not hide it. Anyone who can open the Project can switch to Build and see everything in it. Views make the right things convenient; teams and permissions control access.
If the view you need does not exist, ask for it. Describing the screen you want in a conversation is usually how one gets made.
The Work items rail: your queue
The other rail is where work waits for you. Every run of a Workflow produces a work item, carrying its input, its result, and the trigger that started it.
The rail is a queue, and the thing worth understanding about it is why something is in it. A run that finished is not automatically waiting for you. A work item lands in your queue because the Workflow ended it on a disposition that stops for a person: an amount that did not match, a vendor it could not find, a duplicate it suspected. That is a decision the Workflow was designed to hand over, not a failure. See How a run ends.
Items still moving show a count on the rail, so an in-progress run is visible without opening anything.
One work item: read, correct, send
Opening a work item splits the page: the queue stays on the left, and what the run produced opens on the right.
That detail pane is where the actual work happens. You read what the AI did and the outputs it declared, you change the decision if it is wrong, and you send it on. Corrections you make here do not stop at this one item: they feed back into the Project, so the next batch needs less correcting than this one.
Asking directly
Not all work arrives in a queue. When you need something one-off, ask the Project.