02 / BROWSER · RECORDED RUN
Create customer records from a CSV. Resume with care.
Each customer has a business key and a journal entry. Verified work is kept, uncertain submissions are held for review and unstarted rows can continue.
THE WORK TODAY
Ten new customers need the same form. If the process stops halfway, someone must work out which submissions reached the back office.
WITH A SAVED PROCEDURE
Each customer has a business key and a journal entry. Verified work is kept, uncertain submissions are held for review and unstarted rows can continue.
What happens.
The recording uses a local test back office that accepts duplicate submissions. The process is killed after the fifth customer reaches the server. Four earlier customers are verified; the fifth has no confirmed result. On resume, Ritoko holds that item for review and finishes the other five. The server receives ten submissions with ten unique customer keys.
- Read ten customers
- Submit each customer
- Kill the process at row five
- Resume from the journal
- Run the same file again
WHAT GOES IN
customers.csv
WHAT COMES OUT
9 done · 1 review
What makes it useful.
Use this pattern for customer, supplier or account creation when the destination can confirm each new record. A submitted form is not enough: the workflow should check the customer’s email, record identifier or another business-specific result. The demonstration deliberately adds 700 ms per submission so the interruption can be observed.
THE CHECKS
- ✓ 10 submissions received
- ✓ 10 unique submissions
- ✓ 1 uncertain row held for review
Recorded against a local test back office with a deliberate 700 ms submission delay. The server accepts duplicates; the journal prevents this run from resubmitting them.
Inspect the source Open the interactive showcase