Every AI-driven customization on Plemo lands in a sandbox before it goes anywhere near your live database. That step exists for one reason: it is much cheaper to catch a misunderstanding in a preview than in production, after your team has already booked two weeks of invoices against a field that behaves differently than anyone expected.
The problem is that most sandbox reviews are shallow. Someone opens the preview, clicks the new button, sees something happen, and approves. A month later a report is wrong and nobody can reconstruct why. A good review takes about half an hour of deliberate work, and most of that time goes into testing things you did not ask for rather than the one thing you did.
Start with the spec, not the screen
Before you log into the sandbox, reread the written spec you approved. On Plemo, development does not begin until that spec is agreed, which means you already have a document describing exactly what was supposed to change. Your review is a comparison against that document, not a general impression of whether the system feels right.
Read the spec line by line and turn each line into something you will click. If it says the approval step is skipped for orders under a threshold, you need two test orders: one under it, one over it. If it says a field becomes required, try saving a record without filling it. If a spec line cannot be turned into a concrete test, it was too vague to build against, and the preview is the right moment to say so rather than after go-live.
Test the happy path, then break it on purpose
The happy path almost always works. It is the path the change was built and checked against. Your value as a reviewer is in the cases nobody wrote down.
- Empty values. Leave optional fields blank and save.
- Zero and negative numbers. A discount of 0, a quantity of -1, a line with no price.
- Duplicates. Two lines of the same product, two records with the same reference.
- Cancel and reopen. Cancel a document, then reset it to draft and push it through again. Reversal paths are where custom logic tends to leak.
- Large inputs. Paste a 200 character customer name into a field that will end up on a printed document.
You are not trying to be clever. You are reproducing what a tired person does at 4pm on the last day of the month.
Check what the change touches, not only the change
Odoo's strength is that its apps share the same records, and that is also why a small change can have a wide blast radius. A tweak to a sales order can surface in delivery orders, in the invoice, in inventory valuation, and in the analytic entries behind your margin reports. A change to a product field can reach purchasing and manufacturing.
So after you test the feature, walk one complete business document through the flow end to end. Quotation to sales order, delivery, invoice, payment. Purchase requisition to receipt to vendor bill. Confirm the numbers still tie at each step. This single test catches more real problems than any amount of clicking on the new button.
Open the reports and the exports
Reports are the most common place where a customization looks fine on screen and wrong on paper. If the change affects anything numeric or anything printed, run the PDF, run the relevant accounting or inventory report, and export a list view to a spreadsheet. Check that renamed fields did not quietly disappear from a report someone in finance depends on.
Log in as the person who will use it
Reviewing as an administrator hides access rights problems, and access rights problems are the most frequent surprise after a customization goes live. Administrators see every field and every button, so a new feature that is invisible or read-only for a warehouse user will look perfect to you.
Test with an account that has the same permissions as the people who will do this work every day. If the change involves multiple companies or warehouses, test in the one that is not your default. Better still, have the actual user click through it while you watch, and resist the urge to guide their hands.
Be willing to reject the preview
The honest trade-off here is time. A careful review costs you thirty minutes and may cost another round trip before the change is approved. Skipping it costs you a production incident, a data cleanup, and the trust of the team who has to work around the result. The sandbox exists so that a rejection is cheap, so use it that way.
When something is wrong, be specific. "The discount is not right" starts a guessing game. "On sales order S00042, a 10% line discount shows on the order but not on the invoice PDF" can be fixed immediately. Name the record, the screen, what you did, what you expected, and what you saw. The same precision that makes a good customization request makes a good rejection.
What good looks like
A finished review produces three things: a confirmation that every line of the spec was tested and behaves as written, a list of anything that broke outside the spec, and an explicit decision to approve or send it back. Write it down even if the answer is yes. When the same question comes up in six months, that note is the only record of what was checked.
None of this is unique to AI-driven development. It is standard change control, and it matters more, not less, when changes can be requested and built quickly. Speed is only an advantage if the thing you shipped is the thing you meant. You can see how the request, spec, sandbox and production steps fit together at plemo.ai, and if a change turns out to need design work rather than a build, that is a conversation for custom development.