How it behaves before you quote, and technical notes
Part 4 of 4 · 16. What is possible, what is not, and the limits
Back: The four rules, and when the product has no doorAll chapters
How it behaves, before you quote
| How it behaves | What to do |
|---|---|
| A customer's busiest hour sets the load | run the customer's scale profile on a sandbox before go-live |
| Our Acumatica connector: about 2.75 complete sales a minute per connection | size the busiest hour against it |
| One ERP per company | choose one ERP per company |
| Handheld books online only, and offers no extension point | receiving and counts need a connection |
| A sandboxed function that runs on a till is compiled from Rust | JavaScript started too slowly on a slowed-down till stand-in; a function that only runs on the server may be JavaScript (the Wasm kit) |
| Till keys answer online only, and the request carries no money and no serial numbers | read money and serials from the booked sale, after it is booked |
| An API key acts with its user's role; there are no scoped keys and no server-to-server sign-in grant | narrow the role; one user per app |
| The kit's samples read the shared feed, whose key is not limited to one app (a scoped feed is an extension point: chapter 9); webhooks try three times, then stop | use the feed for anything you must not miss; a webhook is only a nudge |
| Fields made required by a condition are checked in the Desk form only, not on API writes or imports | your service checks its own writes; a save rule of kind required when holds on every save, imports and API writes included (chapter 9) |
| Who may edit a record in a workflow state is checked in the browser only | a save rule of kind locked in state holds on every save (chapter 9) |
| Permissions hide an action, never a field | hide some fields on the till's screens with field rules, as far as the library's list goes (chapter 9) |
| Member pricing goes through promotions, not pricing rules, and a promotion can only exclude customer groups | one promotion per tier that excludes every other group, non-members included (chapter 4) |
| Offline: pricing rules are not applied; loyalty, gift cards and store credit wait for a connection | plan offline behaviour per need |
| One company is one country and one currency | several countries, several sites |
| Our WooCommerce connector does not reserve stock, and takes percentage vouchers only | state it to the customer |
| Labels from the back office and from Handheld print through a desktop utility | use the desktop utility; labels printed from the till use a label layout (Possible today) |
| A warehouse permission does not fence every stock report: on a sandbox, Item Balance (Simple), Warehouse wise Item Balance Age and Value and Stock Ageing in its default layout showed every store to a user with one store, while the other reports and layouts that were run were fenced | test each stock report a branch may open before you promise it, and take away the ones that leak (the card branch-sees-own-stock) |
| The standard automatic reorder submits its request, never a draft | a draft request needs an outside app (the card stock-and-expiry-alerts) |
What is refused, and why
Anything that breaks one of the four rules. The reasons are in chapter 3, and every refusal of an install is on What an app may not do.
When your service is down, and when the till is offline
Offline, pricing rules are not applied, and loyalty, gift cards and store credit wait for a connection (the offline row in the limits table). Each chapter has its own section on what happens when your service is down.
The tests
Every need in your blueprint has a card in the catalogue (or a request for one), and every limit on its card and in How it behaves is written into the customer's proposal.
Technical notes
The exact wording behind some limits in this chapter, with the evidence for them. The lists of what is possible and what has no door are built from the cards in needs/ when the site is built, so they are not written in this file; each card says when it was last checked.
- Feed limit. The kit's samples read the engine feed, whose key is not scoped to one application (a scoped feed is an extension point: chapter 9); webhooks try three times, then stop.
- Rust on the till. A sandboxed function that runs on a till is compiled from Rust. JavaScript compiled to WebAssembly started too slowly on a slowed-down till stand-in; a function that only runs on the server may be JavaScript (the Wasm kit).
- Required-by-condition fields. Conditional mandatory fields are checked in the Desk form only, not on API writes or imports.
- API keys. API keys act with their user's role; there are no scoped keys and no server-to-server sign-in grant.
Back: The four rules, and when the product has no doorAll chapters