One Question, Five Sections: How the CRM Assistant Reads Across Modules

The question sounds like one sentence: which supplier bills are overdue, and is there enough money on the account to pay them? To answer it a person opens five places — suppliers, purchase orders, supplier invoices, bank accounts, bank transactions. An ERP would ask for a report. A CRM assistant has to read.

The assistant in Firmspace is not a database with a chat window. It works through a fixed list of tools, each tied to a section of the CRM. The pages people ask about most have their own tools: contacts, companies, deals, tasks, invoices, expenses, stock, mail, uploaded documents. The long tail is covered by one general reader, browse_data.

That reader knows sixteen kinds of records: warehouses, stock movements, sales orders, quotes, contracts, suppliers, purchase orders, supplier invoices, production orders, recurring invoices, bank and cash accounts, bank transactions, fixed assets, calendar events, conversations and projects. It also opens the custom tabs — automation rules, marketing sections, inventory sections — through a key such as automation:rules.

The important limitation is in the shape of the call. One call reads one kind of record. The reader cannot join two tables, cannot sum across them and cannot follow a relation on its own. It asks for supplier invoices and gets rows; it asks for bank accounts and gets rows; the connection between them is made in the answer, not in a query. This is why a question that crosses five sections takes several steps — and why the answer can be more honest than a report that silently joins the wrong keys.

Each call returns the total number of matching records and only the first page of them. The default page is fifteen rows, the maximum is forty. A search is a substring of up to one hundred characters across a few text fields of that record type, not a full-text search of the firm. A date range uses the entity's own date: the invoice date for supplier bills, the transaction date for bank movements, the event date for the calendar. The order is fixed per type — supplier bills by due date, bank transactions newest first — so the first page is predictable.

Rows come back with names, not internal identifiers. A supplier invoice shows the supplier's name, the amount, what is already paid and what remains open; a stock movement shows the product and the warehouse instead of two ids. The reader resolves those names in advance, which is why the assistant can talk about the bill from this supplier without a second lookup. It also means the row is a summary, not the full document: line items, notes and attachments stay where they are.

The borders are the same as the person's. Access is checked against the section the record belongs to; an employee without finance rights does not get finance rows, and the tool answers with an error rather than an empty list. Only the firm's own records are in scope. Each record type declares which fields may leave the database — totals, dates, names, statuses — and secrets such as bank keys or integration tokens are not among them.

So the five-section question is answered as a walk. First the suppliers, to know who is who. Then their purchase orders, to see what was ordered. Then the supplier invoices, with due dates and open amounts. Then the bank accounts, for the balances. Then the transactions, to see what has already left. Each result narrows the next question; the assistant does not fetch all five at once, and it does not need to. The answer is assembled from five small reads, each of which a person could check.

What the reader cannot do matters as much. It cannot compute an arbitrary figure such as average margin by month, export a table, or sort two hundred invoices by hand. It sees fifteen rows by default and forty at most, so a question about a long period needs a date range, a narrower search, or several calls. It reports the total, which tells the reader what was not seen — a small honesty mechanism that a spreadsheet rarely offers.

One exception deserves its own paragraph. Conversations — WhatsApp, Telegram, the website chat — are text written by outsiders. After the assistant reads them, it marks the turn as exposed, and any change waits for a human confirmation even if automatic mode is on. Records are data, not instructions. The same rule applies to e-mails and uploaded documents, but conversations are where the temptation to obey is highest.

Cross-module questions are exactly where a small firm loses its afternoons: five tabs, two spreadsheets, one person who knows where everything is. The assistant does not replace that person's judgement, and it does not replace a report. It shortens the walk. Ask a narrow question, give it a period, ask for the total — and five screens become one answer with a trail of reads behind it.