The tab closes before the export finishes
An export is running when the customer closes the browser. When they return, the interface offers the same button and no explanation. They start again. The backend may now be doing duplicate work, while the customer has no idea whether either request will produce a usable file.
HTTP 202 Accepted means a request was accepted for processing, not that processing completed successfully. MDN documents that distinction. The product must supply the rest of the story: what was accepted, where its state lives and how the person learns the outcome.
Putting work on a queue is an infrastructure choice. Making that work understandable after the original request ends is a product responsibility.
Give the job an identity the interface can recover
For a hypothetical catalogue export, create a persistent job record tied to its owner and requested scope. Returning to the application should reveal that job, not require the original tab to remember it. The record should distinguish waiting, running, completed, failed and cancelled states in language relevant to the task.
The result needs an explicit home. A completed export might offer a downloadable file with a visible expiry condition. A failed export should retain enough explanation to support a decision about retrying. Neither state should depend solely on a temporary notification that has already disappeared.
Permissions still apply. Knowing a job identifier must not grant access to another organisation's progress, source data or output. Treat the status endpoint and the download path as part of the same ownership boundary.
Report evidence instead of decorative progress
A progress bar should represent something the system can actually observe. If the total work is unknown, show the current stage and a useful status instead of manufacturing a percentage. Processing records and preparing a downloadable archive are different stages, even when the latter has no convenient count.
The message should answer what is happening and whether the customer needs to remain present. If leaving is safe, say so. If additional input is required, explain what is missing and preserve work already completed.
Silence can look like failure even when a worker is healthy. Conversely, a moving animation can disguise a worker that has stopped. Choose operational signals that distinguish those cases and expose a plain explanation when the expected state stops changing.
Retry the work without repeating its effects
A retry button is a business decision, not just a request to run the same function again. For an export, duplicate computation may be tolerable. For a job that sends invitations or updates orders, repeating completed effects can cause real confusion.
Define which parts can safely repeat and which require a recorded completion decision. Keep attempts distinguishable from the underlying job so support can explain what happened. The customer should not have to infer whether a new click creates another task or resumes the existing one.
Cancellation also needs honest wording. A request to stop may arrive after an irreversible action. If the system can only prevent the remaining work, say that. A cancelled label must not imply that already sent messages or applied updates were undone.
Close the browser during a test this week
Choose a job that matters to customers. Start it, leave the page, sign in elsewhere and find its state again. Then stop a worker, retry after a partial result and request cancellation near completion.
For every transition, check the customer explanation, the persistent record and the actual external effect. Confirm that support can identify the relevant attempt without asking for browser console output. The job is part of the product when its outcome remains understandable after the original spinner, tab and connection are gone.