What should happen when only some bulk assignee changes fail?

Start with what the operator needs to finish

Imagine changing the assignee on 100 support tickets: 90 changes are confirmed successful, 7 are confirmed unsuccessful and 3 outcomes are unknown. “Some updates failed. Try again” leaves the operator guessing whether to resend all 100 or the remaining 10.

I would frame the requirement as keeping completed changes intact while resolving the remaining items. The fictional scope is assignee changes only; deletion, refunds and customer messages need different safeguards. Record the scope and completion conditions before drawing the button.

Completion means every selected item has an accountable outcome, confirmed successes stay out of retries, and unknown outcomes are not relabelled as failures. These are requirements to implement, not claimed production results.

A finished job does not establish success for every item

Zendesk’s public documentation distinguishes a bulk job’s status from its item results. That suggests the first integration question: can our screen retrieve the result for each ticket, or does it only receive a job-level status? The source links are at the end.

Ask operations to walk through what they see and do after a failure. Ask engineering to distinguish request acceptance, item outcomes, result lookup, the current assignee and the change history. A label is not useful unless the system can support it with evidence.

Keep a short inventory of required information, whether it exists, who checked it and what needs deciding if it is missing. A missing response establishes uncertainty, not that a change was never applied. The counts below are fictional design inputs.

Why I would replace the initial “retry everything” idea

Resending all 100 is the simplest interface, but it includes 90 completed items. Another operator might have reassigned one of them meanwhile. Even writing the same value can have notification or history effects that need checking.

Resending the 7 failures plus 3 unknowns is still unsafe: it does not resolve whether those 3 changes were already applied. For this case, retain item outcomes and reconsider only confirmed failures after checking their current conditions.

This costs more than adding a button: persistent results, a lookup screen and status refresh are needed. Start with assignee changes; decide selection limits and refresh intervals from operational volume and server constraints. Record both the reason for the choice and this implementation scope.

Split the seven failures by what must happen next

For the example, split the 7 failures into 3 temporary processing failures, 2 permission failures and 2 update conflicts. “Failed” here means the requested change is confirmed not to have been applied. A timeout or disconnected response alone belongs in the unknown category.

Immediately before another attempt, the server must check current permission, whether the ticket is still eligible, and whether the relevant assignee or business conditions have changed. A disabled button cannot enforce that contract by itself.

For a conflict, show the latest assignee alongside the intended assignee and ask the operator to reconsider. Fetching fresh data is not permission to overwrite it. Connect this decision to the conflict reconfirmation specification and the concurrent-update QA case.

Look up the original request for the three unknown outcomes

Use the reference associated with the original request to retrieve its outcome. A current assignee equal to the intended value does not prove that this request succeeded: someone else could have made that change. Look for a linked request and item result.

Move an item to complete when that evidence confirms success; use the appropriate failure path when non-application is confirmed. If lookup remains unavailable, retain the unknown state and last-check time and hand it to operations. Resolve the review deadline, responsible team and escalation rule before launch; elapsed time alone must not silently become evidence of failure.

Zendesk makes job status data available for one day after creation. Our own retention policy is a separate decision. Capture the required outcome evidence before external lookup becomes unavailable, with defined access and retention. This does not require copying customer messages or all personal data.

Make the next action visible alongside the totals

Show selected 100, completed 90, failed 7 and unknown 3 on a consistent basis. Filtering down to seven failures must not replace the overall request total. Operators should be able to reopen the same request from task history after closing or refreshing the screen, with a last-check time while outcomes remain pending.

An item row needs a ticket reference, previous and intended assignee, verified state, reason and next action. Open message content only when necessary and within the operator’s permission. Limit selection to eligible items and explain excluded items.

Retry first opens a confirmation of the currently checked subset and intended change. Executing it creates a new request linked to the original. Keep the original failure record rather than rewriting history as if every item succeeded on the first attempt.

Connect the proposal, specification and handoff

The proposal explains why all-item retry was rejected, why assignee changes are the current scope, and what counts as completion. The specification turns that decision into conditions, UI text, actions and records. Link them by a descriptive name such as “item recovery rules” instead of repeating the entire argument.

Ask engineering to distinguish a sent request from an applied change. Agree how the server identifies duplicate submissions and returns the existing result. Merely generating a reference does not enforce deduplication: storage scope, lifetime and a changed request payload need decisions too.

List unresolved decisions with an owner role and due point. Retention, maximum selection size and lookup-failure alerts remain launch prerequisites, not details to quietly invent in a draft.

Ask AI to find missing conditions before rewriting the document

For this task I would use AI to compare the state table with the proposed UI text. Give it fictional counts, agreed rules and explicitly unknown decisions, rather than private tickets or internal policy. The reusable prompt below is an example, not a transcript of a completed AI session.

Check each proposed sentence against the state table. If an answer merges the 3 unknown items into failures, a correction could be: “Non-application is not confirmed for those three items. Remove them from retry selection and write a result-lookup path.” This is also an illustrative correction, not a quoted exchange.

Record the original rule, proposed change, adoption or rejection reason and affected specification. Suggested retention periods or retry counts become policy questions for confirmation. The final wording must let engineering implement a condition and QA verify it.

Review a fictional bulk assignee change. Of 100 tickets, 90 are confirmed successful, 7 confirmed not applied and 3 have unknown outcomes. The 7 failures are 3 temporary, 2 permission and 2 update conflicts. Exclude successes from retries; look up original results for unknowns. Even confirmed failures require current permission, business-condition and version checks.
Compare each state’s UI text, operator action, server check and saved record in a table. List missing or conflicting conditions with reasons. Do not invent API features, polling intervals, retention periods or performance results; leave questions for confirmation.

Test what a second click does, not just the error label

For every QA case, link input conditions, operator action, expected UI and expected stored records. Checking only a partial-failure message can miss completed items being executed again. Inspect submission counts and item execution records too.

The supplied example checks counts and retry-selection rules. It does not connect to a real support platform. Integration QA must reproduce concurrent edits, lost responses, refreshes and permission changes in the actual test environment.

Block launch if unresolved outcomes become a completed request, successful items execute again, or a changed assignee is overwritten without reconfirmation. When fixing one of these, update both the corresponding specification and QA condition.

Leave a handoff the next person can use

Bundle the issue and scope, decision rationale, state and interaction table, request/result record contract, QA cases and open decisions. Explain which document answers which question. Use the same descriptive case name across them so the next person can find the connections.

During operations handoff, walk through finding an unresolved request, reading its evidence and assigning review to an authorised role. Verify that a new retry request remains linked to the earlier outcome. Copy the handoff below and fill in the unresolved policies for your own system.

Issue: recover partial results of a bulk ticket assignee change.
Scope: assignee only; no deletion, refund or customer messaging.
Input: selected 100 / completed 90 / failed 7 / unknown 3. Failure means confirmed non-application.
Decision: no retry-all. Exclude successes. Look up original results for unknowns.
Retry: resolve the cause and recheck current permission, business conditions and version; confirm subset and intended change. Link a new request to the original.
UI: retain total counts; state filters; exclusion reasons; latest/intended assignee; last-check time; task-history re-entry.
Records: request scope, actor, item results, before/after values and linked attempts. Do not collect message bodies by default.
Decide before launch: maximum selection, refresh interval, duplicate scope/lifetime, result retention/access, unresolved-outcome deadline/owner/alerts.
Block launch: repeated successful items, unknowns relabelled as failures, conflict overwrite without reconfirmation.
Before adoption: integration QA in the real test environment and responsible-role confirmation are required.

Sources and example conditions

A planning example by WekeyLab AI, informed by public API documentation. Counts and failure categories are fictional inputs. No real service deployment, executed AI dialogue or operational improvement is claimed. English and Chinese localize the same Korean case. Sources checked: 2026-09-25.

Zendesk — Job Statuses

Zendesk — Protecting against ticket update collisions