In this insight
You can test a business workflow without copying production data by using synthetic test data: invented records designed to exercise its rules, decisions and failure cases. Start with how the work should happen, then create examples that challenge it. This is a useful starting point, not a replacement for every later integration or real-world check.
A team wants an app. The first question is often, “Can you send us your data?” Sometimes that is necessary. But asked too early, it can distract everyone from a more important question: what should the app actually do?
A spreadsheet shows what was recorded. It does not always show who checked it, which conversation changed the decision, or why an exception was allowed. Copying those rows into a new interface can preserve the confusion in a more expensive form.
A better starting point is the work itself: the request, the people involved, the rules they follow and the evidence that tells them it is finished. That is the beginning of an operating model—a clear account of how work gets done.
Begin with the work, not the records
Ask someone to walk through a normal day. Where does a request arrive? Who picks it up? What must be known before it can move? Who can say no? What happens if nobody answers?
These questions need business knowledge, not a copy of every customer record. A blank form, a made-up example and a conversation with the person doing the job may reveal more than thousands of unexplained rows.
The distinction matters. “We need approvals” describes a feature. “A supervisor checks submitted hours, and an approved entry cannot be changed without another review” describes behaviour. The second statement gives a builder something to implement and a reviewer something to challenge.
This does not mean planning every detail before building. Start with one useful journey. Make its important decisions explicit, build a small version and learn from it.
Make one ordinary request precise
A crew lead records the week’s hours. A supervisor checks them. If something is unclear, the supervisor sends the submission back with a reason. The crew lead corrects it and submits a new version.
Draft → Submitted → Approved. Or: Submitted → Changes requested → Revised → Submitted.
“Approved” means a named, authorized person accepted a particular version. It does not automatically mean payroll was sent, money was paid or another system received it.
Now give each rule a test. A draft may be edited. A submitted version must remain available to the reviewer. A requested correction must show its reason. Approval must record who decided, when they decided and which version they saw.
This small model connects people, records, states and decisions. Screens come next: the entry form, the review queue and the history. Each screen exists to support a defined piece of work, rather than to fill a dashboard.
Test the moments that break the happy path
An ordinary example shows that a journey is possible. Difficult examples show whether its meaning survives real use. Try these before introducing live records:
These are not merely technical edge cases. They answer business questions: can the same work be counted twice? Can an old decision affect a new record? Can somebody act after leaving the team?
People must agree on the answers. AI can help propose scenarios or code, but it cannot decide what your organization means by “approved.”
- The button is pressed twice. A repeated submission should not create two approvals or send the same message twice. The user should see whether the first attempt was saved.
- The record changes during review. If a supervisor is looking at an old version, the app should ask them to review the current one—not silently approve changes they never saw.
- Someone loses access. A person who could review yesterday may not be allowed to review today. An open browser tab should not preserve authority after it has been removed.
- The request is withdrawn. Cancelling it should stop the next action where that is still possible. Submitting it again needs a clear rule: restore the old request or create a new version?
- A notification fails. A saved submission and a delivered email are different facts. The app should preserve the work and report the delivery problem truthfully.
What is synthetic test data?
Synthetic data means invented records created for testing. For this example, use fictional people, projects and hours. Include missing fields, unusually large entries and two similar names. The aim is not to make every screen look tidy. It is to make the important rules visible.
Inventing data is different from replacing names in a real export. A record may still identify someone through its dates, location, notes or an unusual combination of facts. Do not assume that changing a name makes a file safe to share.
Made-up records also have limits. They may miss old formats, unexpected attachments, busy periods or the way people actually correct mistakes. Passing these tests is evidence about the tested scenarios—not proof that every real situation will work.
For this lesson, we use purpose-built fictional examples, not a statistical copy of a production dataset. Synthetic generation can also use real source data; the label alone does not guarantee anonymity. IBM’s documentation on fabricated test data describes the general testing approach. Our focus here is choosing examples around business rules before collecting live records.
Use invented records to test the rules. Use a controlled launch to discover what the rules and tests missed.
Treat real use as another stage of learning
Before a first live release, agree who can access real records, where they will be processed and what support is available. Identify which outside services receive information. Testing with synthetic records does not, by itself, make the finished service private or keep every processing step local.
Choose a small first group and define what people will check. Can users complete the journey? Do totals reconcile? Are failures visible? Does the app remain usable under the expected load? Who can pause the rollout, and how will the team recover if a change goes wrong?
Then compare real behaviour with the model. Some surprises require a software fix. Others reveal an unclear rule. Keep those decisions connected to the project so the next builder understands why the behaviour changed.
This is the point of human-governed development: people shape the work, inspect the result and decide when to proceed. The first release is not the end of that responsibility.
Model conversion exercise
Use this exercise with a real workflow and the people accountable for its outcome. Record disagreements as modeling questions instead of silently choosing an answer.
Choose one recurring request. Write down its trigger, owner, states, approval rule and proof of completion. Create three invented records: one ordinary, one incomplete and one submitted twice. Ask two people to predict the correct outcome independently.
If their answers differ, you have found a useful question before it became a production problem. Resolve it, record the rule and make it part of the next test.