The order is the evidence
A complaint names a product and roughly a date. The order turns that into an exact item, variant, purchase date and - where it was captured - a lot code.
Suggested, then confirmed by a person
When a complaint arrives, candidate orders are suggested from what it actually says. Someone confirms which is right, and the record shows who did and when.
Never automatic. A wrong match attaches one customer’s purchase to another person’s safety report. Software guessing at evidence is not evidence, so the match is a suggestion until a human accepts it.
What the confirmed order carries
- The exact product and variant, as sold at the time
- The purchase date
- The order number, for anyone who needs to trace it
- The lot code, where it was captured
Historical identity is never rewritten. If you rename a product or change a label next year, the case keeps the product as it was when it was bought - because that is what the complaint is about.
What we ask Shopify for
Three read-only scopes, and nothing else: read_products,
read_orders, read_customers.
We removed two scopes we had requested and were not using. Asking for data an app does not use is the thing an access review exists to catch, and it should not need a reviewer to catch it.
The app never writes to your store. It does not change orders, edit products, or contact your customers on your behalf.
Bringing history across
Existing complaints import from a spreadsheet, with a dry run that shows exactly what would be written before anything is.
A row with no readable received date is rejected, and cases already past their deadline import marked overdue. Stamping today’s date on two years of history would make every imported case look on time. That is not a data cleanup - it is a manufactured compliance position, and the import refuses to create one.
See it on a real case
Ten steps, about four minutes, no signup. All data fictional.