Offer a defined action
I would build this illustrative application around named operations: upload a dataset, generate a report, update permitted configuration, or inject test records. Each operation defines allowed inputs, destinations, limits, and an accountable owner. The interface exposes those choices without handing users general infrastructure credentials.
Assume authenticated users and a durable job service. Test execution has separate workers, credentials, and destinations that cannot trigger production responses. A checkbox or a label on synthetic records is insufficient isolation.
Inspect inputs before using them
Place uploads in private quarantine under generated identifiers. Enforce file-type, size, and decompression limits; do not trust an extension or declared content type. Run required scanning and parsing in a restricted environment with time and memory bounds. Failed or unavailable checks prevent application.
The preview displays escaped values, accepted rows, rejected rows, and proposed mappings. It does not execute uploaded content. Report parameters and configuration fields receive equivalent validation. Scanning reduces risk but does not prove an arbitrary file is harmless.
Bind review to an immutable intent
Show the exact destination, selected operation, validated input version, and expected changes before the user applies a consequential write. Record consent against that intent; changing the file, mapping, or destination requires another review. A report request can proceed directly when it has no comparable write effect.
The server enforces the validation and approval sequence. It atomically records the job and its dispatch intent before acknowledging acceptance. Configuration writes also check the target version, so a stale preview cannot overwrite someone else's newer change.
Recover without repeating completed effects
A submission key is scoped to the caller and immutable intent. Repeated submissions return the existing job; reusing the key with changed arguments is rejected. Workers recheck authority before each write and use pinned processing rules. Job state records completed items and failed items separately.
Each destination write needs an operation identifier recorded atomically with its effect, or an equivalent destination guarantee. A job ledger alone cannot prevent duplicate external effects. After an ambiguous timeout, reconcile the destination before retrying; if that is impossible, stop automatic retries. Keep deduplication records through the supported recovery interval.
Show outcomes people can act on
The interface distinguishes queued, validating, running, partially completed, failed, canceled, and completed states. Progress comes from recorded work, with an unknown total shown honestly. Per-item errors explain what can be corrected without copying protected payloads into ordinary logs.
Cancellation stops further work where possible; it does not undo committed changes. Review compensating changes separately. Results, previews, status endpoints, and downloads require current access. Notifications link to the protected job. Give inputs, temporary files, and outputs explicit retention and deletion rules.
Keep the tool smaller than its platform
Watch queue age, stuck jobs, validation failures, partial outcomes, and destination errors. Keep a support timeline of actor, intent version, approval, processing version, and effects. A retry after a correction creates a linked new intent.
Self-service reduces repeated handoffs but creates an application to maintain. For infrequent, exceptional work, a reviewed script and an operator may be simpler. Expand the action catalog only when ownership, limits, and recovery behavior are clear.