> ## Documentation Index > Fetch the complete documentation index at: https://zenofirm.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # The console > A tour of the firm workspace at app.zenofirm.com: what is on each page and which of them is waiting on you. The console holds the work that needs a person's review. It is at [app.zenofirm.com](https://app.zenofirm.com). Its shape is deliberate. The console shows what is waiting and takes the decisions that are a person's: approve a plan, exclude a line, approve a claim. The work itself — coding, matching, teaching a rule, setting up recurring work — is done through the assistant the firm has connected, and the console shows the result. It shares its shape with the local console that ships with [Zeno for QuickBooks Desktop](/docs/quickbooks-desktop/console), so a bookkeeper who works in both editions is not learning two navigations. | Section | What it holds | | ----------- | ------------------------------------------------------------------------------------ | | *(top)* | Today | | **Work** | Inbox, Bank feeds, Plans, Runs — the pipeline in order | | **Memory** | Coding rules, Knowledge, Work log — what Zeno has been taught and wrote down | | **Clients** | Clients, Bank connections, Expense cards, Engagements — everything set up per client | | **Firm** | AI clients, Team, Billing, Notifications | Nothing in the rail folds: every page is in the same place on every page. ## The company picker Almost every page is about one client's books, and the sidebar's picker scopes them all. **All companies** shows the whole firm. Every page has a real address, and the address carries the company: `/knowledge?company=Ridgeline%20Properties%20LLC`. Send a colleague the link rather than a sequence of clicks. ## Today One queue, in the order the work should be burned down: what is overdue, what is due, what is waiting on a review, and what is merely worth knowing. It gathers from everywhere — engagement periods coming due, plans nobody has decided on, documents sitting in the inbox, read models that have gone stale, runs that need attention. A row appears exactly once, under the most urgent heading that claims it. ## Inbox Bills, receipts, and statements that have arrived by email or upload, waiting for somebody to say whose books they belong to and what they are. See [the firm inbox](/docs/cloud/documents). ## Bank feeds Every staged bank and card line for the picked client, whatever door it came in by — a bank connection, an imported statement, a company card — with what it is coded to, whether the ledger already holds it, and whether a claim is riding on it. The tabs are the questions a bookkeeper asks: needs coding, rule suggested, ready to plan, claims to review, awaiting cardholder, linked. What a person does here: select lines and **Build plan**; **Exclude** a line with a reason, or restore one; **Link** a line the scan matched to a ledger entry; **Approve** or **Send back** a submitted claim; **Import statement**. Nothing on the page writes a coding — that comes from rules, history, and the assistant. See [the queue](/docs/cloud/bank-feeds) and [expense claims](/docs/cloud/expenses). Cardholders get their own narrow page instead. ## Engagements The recurring work a firm has committed to: monthly closes, quarterly filings, weekly reviews, annual returns. An engagement carries a cadence, a due rule, and the steps it consists of; Zeno materializes each period as it comes and surfaces it on Today as it approaches. The page shows which periods are open and how late, what the last agent run left behind, and which machines have checked in. **Retire** ends an engagement; no new periods open. An engagement is set up through the assistant (`qb_create_engagement`), which also binds the playbook an agent runs for it, marks a period done or skipped, or **parks** one behind a follow-up date when it is waiting on somebody else — out of Today without pretending it is done, back on the date chosen. See [working on a cadence](/docs/cloud/cadence). Nothing here runs on a scheduler. Periods appear when the page is read, because not looking is exactly what makes something overdue. ## Plans The review queue, and the middle of the product. A plan lists every proposed entry with its date, counterparty, amount, coding, source, and the verdict preflight reached — ready, worth checking, blocked, already posted. Work down it, decide lines, and record an approval or a rejection in your own words. Both are decisions and both leave a trace pinned to the exact plan that was read. See [plan, review, apply, reverse](/docs/cloud/governed-work). ## Runs Every apply and every reversal, newest first: what posted, what was skipped and why, what failed with QuickBooks' own message, and the QuickBooks id each entry became. Reversals appear in the list like any other run, linked to the run they undo. ## Work log What was done and why, by company and period. Add entries directly — the log is a record for people, and a person can write in it as well as an agent can. The run journal records what was posted in enough detail to reverse it. It cannot say what was decided or what is still open. That is what this is for. ## Knowledge and coding rules The two things the workspace has been taught, each readable and editable by the person whose judgement they encode. **Knowledge** is what a bookkeeper knows about a client's books that no rule can express, anchored to the names it is about so it surfaces when those names come up. Entries land as drafts; confirming one is what makes it start surfacing. **Coding rules** are mechanical: this descriptor means that account. Each shows what it matches, what it fills, whether it fills automatically or only suggests, how many times it has been used, and when it last applied. ## Clients The firm's client companies, their connection state, and how fresh each read model is. **Add a QuickBooks company** runs the Intuit consent flow. After the first sync, **First look** shows observations and draft knowledge drawn from the books. A person must confirm a draft before it guides later work. Disconnecting lives here too, beside connecting. Zeno stops syncing and can neither read nor write those books until somebody reconnects. The roster and mirrored books remain in place, as do the work log, plans, verdicts, and runs. **Remove** appears after a company is disconnected. It removes the company from the roster and deletes the mirrored books. Plans, verdicts, runs, and work log entries stay readable. ## Get started The page a new workspace lands on, and the only one that leaves the sidebar when it is finished. Two steps: connect the AI you already use — Claude, ChatGPT, Claude Code, Codex, Cursor, or VS Code, each with its install link or its exact command already carrying your endpoint — and connect a QuickBooks company. The AI step ticks itself off the moment a client completes approval. ## AI clients The same install links and commands, plus the MCP endpoint, the firm's connect code, and the clients that have already authorized themselves, with the date each connected and a **Disconnect** beside each one. Disconnecting revokes that client's access immediately and leaves everything it did on the record. See [connecting an AI client](/docs/cloud/clients) and [disconnecting a client](/docs/cloud/clients#disconnecting-a-client). ## Billing Your plan, what it includes, what you are using, and the card. Owners only. ## Setup pages Under **Clients** and **Firm** rather than among the daily queues, because these are the pages you visit when something is being wired up rather than when work is waiting: * **Bank connections** — connect a bank login, map an account to the QuickBooks account its money lands in, re-authenticate a lapsed connection. * **Expense cards** — mark a fed account as an expense card and record its cardholders. * **Notifications** — choose firm emails, the local timezone and digest hour, and when a quiet scheduled agent counts as stopped. Each person controls their own opt-outs. See [notifications](/docs/cloud/notifications). * **Team** — who is in the firm and what each of them may do. See [people and roles](/docs/cloud/team). ## Support **Support** sits beside **Sign out** rather than in the main navigation. The form sends the signed-in person's contact details, firm, role, product build, and the page they came from. It does not attach ledger data or AI-client conversations. See [troubleshooting the firm workspace](/docs/cloud/troubleshooting) for the checks to make before sending a report.