A sales pipeline wired to the accounting system and the proposal tool

Staff press a button on the deal to add it to accounting. The scenario reads the deal and its details by GraphQL, searches accounting for the customer, and either reuses the match or creates the customer, then creates the job beneath it and writes both ids back to the deal. Matching first keeps one customer per client however many deals they have.

When an estimate or an invoice is created in accounting, a linker waits briefly, reads the document through accounting's API, finds the deal it belongs to, connects the document to the deal on the board and stamps the deal's id on the invoice in accounting. An invoice that matches no deal takes its own route and is not linked.

A roll-up scenario listens for changes to linked estimates and invoices. A router sends each event type to its own route, where GraphQL reads the linked records, a code step does the arithmetic and a mutation writes the deal's value. For invoices it pauses first, then reads the totals from accounting itself, so the pipeline shows what was actually invoiced.

A second button creates the proposal. If required fields are missing, the scenario sets a status and posts an update on the deal saying what is missing. Otherwise it creates the document from a template prefilled from the deal, the customer and the rep, waits for it to render, downloads the PDF and files it on the deal. A webhook from the proposal tool brings status changes and the signed PDF back to the deal.

One scenario fills the deal's project site address: it keeps one already set, geocodes a typed address, or takes the customer's address from accounting and geocodes that. Another stamps a readable deal id on every new deal. Each board webhook answers the board's challenge handshake on its first route, so every subscription verifies itself.