Otter Beam / Guides
How data flows in Otter Beam Workspace
By Otter Digital Pte. Ltd. · Updated October 17, 2026
Otter Beam Workspace keeps Sales & CRM, Procurement & Purchasing and Project Management in one company database on the company's own computer. When something happens in one module that another module needs to know about, Otter Beam passes it on automatically. We call each of these a hand-off. This page lists every hand-off: what starts it, what it creates or changes, when it does nothing, and what happens when it cannot finish.
How every hand-off behaves
- Same moment, same database. A hand-off runs in the same database transaction as the action that started it. Either both are saved or neither is; nobody can see a half-finished state.
- Your action always counts. If the hand-off itself cannot finish (for example, a vendor is on hold), the action that started it is still saved. Accepting a quotation stays accepted even if the follow-up step fails. The failed hand-off is rolled back on its own and reported.
- Recorded by "Otter Beam". Records a hand-off creates or changes are written by the system, not by a person or the agent, and every change goes into the audit log with before / after values and the hand-off number (F1–F8) as the note.
- Visible in Data health. Each run is logged as OK, Skipped (nothing to do) or Failed, with the exact reason. A failed run also opens an error. Failed runs can be retried from Data health once the cause is fixed; a retry only does the part that was not done yet. Errors can be marked resolved.
- Chains are limited. One hand-off can start the next (an accepted quotation creates a sales order, which creates a project). Chains stop after four steps so a configuration mistake can never loop.
- No re-keying. Every created line points back to the line it came from, so quantities, prices and progress can be traced from the quotation to the final payment.
Sales line
| # | Starts when | What it does | Does nothing when | Fails when |
|---|---|---|---|---|
| F1 | A lead is converted | Creates the customer (company or individual) if the lead has none, a primary contact if the lead names one, and an opportunity linked to both. The lead is marked converted. | — | The records cannot be created (reason shown in Data health). |
| F2 | A quotation is accepted | Creates a confirmed sales order with the next order number, copying every quotation line and the site address; marks the quotation converted and the opportunity won. A variation quotation instead adds its lines to the original order and updates its totals. | — | The order cannot be created. The quotation stays accepted. |
| F3 | A sales order is confirmed (including by F2) | If the order contains items that start a project, creates the project (budget = those lines' subtotal) and its tasks from the project template, with dates in sequence and finish-to-start dependencies between them. | The order has no project items, or already has a project. | No project template is available. The order stays confirmed. |
| F8 | A payment is confirmed, allocated or voided; an invoice is issued or voided | Recalculates paid and due amounts on every affected invoice and vendor bill and moves them to partially paid / paid; updates the sales order's "Invoiced x% · Paid y%" and the purchase order's payment status. Only confirmed payments count. | The payment is not allocated to anything yet. | — |
| — | An invoice is created from a sales order with no lines yet | Pre-fills it: a standard invoice copies the quantities not yet invoiced; a deposit or progress-claim invoice adds one line for the agreed percentage, minus earlier claims. | — | — |
Procurement line
| # | Starts when | What it does | Does nothing when | Fails when |
|---|---|---|---|---|
| F4 | A purchase request is created for a project | Links the request to the project. Lines added without a price are pre-filled from the preferred vendor's last price (or the lowest known price when no vendor is preferred). | — | — |
| F5 | A purchase request is finalised | Splits the request into one draft purchase order per vendor, at each vendor's last purchase price. When every line is on an order, the request is marked ordered. | — | A vendor is on hold or blocked, or a line has no vendor ("Vendor Tampines Paint & Coatings is on hold."). Orders for the other vendors are still created; Retry later creates only the missing ones. |
| F6 | A goods receipt is posted | Adds the received quantities to the purchase order lines and moves the order to partially received / received ("Received 90%"). | — | — |
| F7 | A vendor bill is created from a purchase order, its lines change, or it is finalised | Pre-fills the bill from the order, then compares billed quantity and price with what was received (three-way match): matched, quantity mismatch ("Qty mismatch: billed 40, received 38"), price mismatch, or no receipt yet. On finalise, records what has been billed on the order. | — | — |
Projects
| Starts when | What it does |
|---|---|
| A task is started | Refused while a task it depends on is still open ("Waits for: Site survey"). |
| A dependency is added | Refused if it would create a loop. |
| Tasks, assignments, estimates or logged hours change, or F3 creates tasks | Recalculates each affected person's weekly load for the next weeks; the Workload view shows over-allocation in red. |
What the AI agent can and cannot do
The agent never writes to the database directly. It sends structured requests that go through the same rules as a person: the same validation, the same hand-offs, the same audit log. Drafts it creates have no business effect until approved; anything that commits the company (finalising, sending, paying) waits on an approval card that the owner approves or rejects, usually from their phone. The agent's read access is limited to structured, read-only queries. Any answer that contains personal data (names, emails and phone numbers of contacts and staff) is marked as such, and the agent is instructed to use it only for the task at hand.