How order information moves from QuickBooks to your customers — without anyone at J2 typing it twice, without exposing your accounting system, and without adding a second place for your team to look.
This page describes Revision C, from July. Two of its conclusions have since been overtaken and it should not be used to plan work:
Current design: the order confirmation walkthrough.
This is the path an order takes from the moment a deposit lands. The break in the middle — the manual re-entry — is what everything downstream waits on.
Every won job is re-keyed from QuickBooks into the tracker by hand. Slow, and where drift between the two systems begins.
Order Confirmation Form Rev 2.0 says it plainly: nothing starts until every item is confirmed and approved. Today it goes out as a PDF and comes back signed — or stalls somewhere no one can see.
The customer can't see that their own missing ship-to address is holding the lead time at zero. They find out when they call to ask why nothing has moved.
Order data enters once, in QuickBooks, and flows outward automatically. Critically, this adds no second internal screen — the tracker stays where your team already works, and customer confirmations land in it as columns rather than in a new inbox somewhere else.
The change from the first draft. An earlier version of this drawing showed a separate J2-facing screen alongside the tracker. That was a mistake — it recreated the very duplication this project exists to remove, just at the screen layer instead of the keyboard. There is now exactly one place J2 looks, and which one it is depends on the tracker question below. Never both.
Before designing anything we needed to know whether the double entry could actually be removed — because if it couldn't, the tracker would have to be rebuilt. It can.
The mechanism. QuickBooks Online publishes webhook events when an invoice or payment is created or updated. Those events carry identifiers rather than full records, so the sync service reads the complete order back through the QuickBooks API and maps only the fields J2 has approved. AppSheet accepts inbound writes through its own REST API, so the tracker row can be created — and later updated with the customer's answers — programmatically.
| What we verified | Result |
|---|---|
| Webhook coverage | Invoice and Payment, on create, update, delete and void |
| Payload contents | Entity type, id, operation and timestamp only — a follow-up read is required by design |
| Endpoint requirements | Public HTTPS with HMAC-SHA256 verification of Intuit's signature header |
| Writing to the tracker | AppSheet REST API accepts add, edit and delete from an external service |
| Rate limits | 40 requests per minute per company file; webhooks don't consume read credits |
| Cost at J2's volume | None. Free-tier allowance is far beyond this workload |
The tracker stays the shop's tool and fills itself. Customer answers arrive as new columns on the row Levi already reads. Nobody learns anything new — the re-typing simply stops.
If AppSheet's plan or sync behavior gets in the way, the Operations Platform takes its place — same columns, same archive, same attachments, no re-entry. That platform is also available by choice, not only as a fallback.
Either way the customer portal is unaffected. It reads the data layer, not the tracker — so it ships on schedule regardless of how this resolves.
A customer confirming their address shouldn't require anyone at J2 to open a new application. Three mechanisms cover everything, and two of them are things your team already uses.
| Mechanism | What it carries | Why this form |
|---|---|---|
| Tracker columns | Confirmation status, date completed, which items are outstanding, submittal required or waived, customer questions | It's the row Levi already reads. State belongs next to the job, not in a separate queue. |
| A customer completed their confirmation and the clock has started; a customer asked a question; a submittal was approved | Push, not poll. Nobody has to remember to go and look, and it lands where J2 already works. | |
| Watchdog alert | The sync missed a scheduled run, or a specific record failed to import | This is the one that can't live inside the tracker — see below. |
Why the watchdog sits outside. A health indicator written by the sync itself goes quiet exactly when it should be shouting: if the sync dies, the indicator freezes on its last value and the tracker looks perfectly normal while going quietly stale. So the tracker carries a timestamp — "last sync 8:02 AM" — because a stale timestamp is obviously wrong to anyone glancing at it, while a stale "OK" is invisible. The actual alarm runs on its own schedule, outside the sync, and asks one question: did it run? A separate failure mode — one record that won't map while everything else is fine — is written into the tracker as a flagged row, so a missing job shows up in the same place as every other job.
Two distinct pieces of work, sharing one foundation. The first is what we agreed. The second exists because the same data layer makes it inexpensive — not because the first needs it.
Order data enters once. The tracker fills itself. Customers get a live order confirmation, a visible lead-time clock, documents, photos and messages — and J2 stops fielding "where is my order" calls.
| Double entry | Removed |
| Internal screens added | None |
| Customer-facing surfaces | One |
The tracker as a purpose-built interface rather than a spreadsheet: submittal state on every order, a screen per sales rep reachable from outside the business, and a searchable archive with photos, work orders and cut files attached.
| Replaces | The AppSheet tracker |
| Required for the portal | No |
| Becomes necessary if | AppSheet can't be automated |
None block the design. All shape the build, and each is quicker to answer in a room than over email.
| Question | Why it matters | |
|---|---|---|
| 1 | How do customers get in — accounts, or a link per order? | Accounts suit repeat customers and give them a portfolio of jobs; per-order links ask nothing of the customer at all. This is the one decision that shapes the login work, so it wants settling first. |
| 2 | How much can a customer do beyond looking? | Confirming their own form is clearly safe. Requesting changes is useful but creates work. Where the line sits is an operations decision, not a technical one. |
| 3 | Which tracker columns are the customer's business? | Material source, hardware status and internal review stay behind the wall. The proposed customer-visible set is in the portal preview — it needs your redline. |
| 4 | What counts as "everything complete" on an order? | The clock starts when the confirmation is complete. Since submittals aren't always required, we need the rule that decides when an order qualifies. |
| 5 | Is the tracker worth replacing? | Not a question for Thursday. Once the sync is live and the re-typing has stopped, you'll know whether the spreadsheet is still holding you back. |
Next step on our side. Access to QuickBooks and to the tracker. Everything here is designed from the 28 July conversation and your own Order Confirmation Form — confirming it against live data is what turns it into a build.