Telecom Install: Eleven Stages, a Skip Button, and a Parent That Won't Stop

Model the optionality, do not patch around it

Two legitimate approaches:

• Alternate stages. The stage exists in the lifecycle but the case enters it only when a condition holds, so for a prepaid customer the Credit Check stage is never entered and never appears as work.
• Branch in the process. A decision in the preceding stage's process routes the case down a different path - the skip is a normal outcome of the flow, visible in the process diagram and the audit trail, not a manual override.

Either is fine; the current local action is not, for two reasons.

Why the Skip button is broken

1. The open assignment is not the assignment that performs the transition. A change-stage from a local action moves the case but leaves the original assignment pending, so the inbox fills with work pointing at stages the case has already left. Perform the transition from inside the assignment's flow (a flow action whose decision routes onward), or if a stage change from an action is genuinely required, complete or route the open assignment as part of the same step and verify nothing is left behind.
2. It is invisible. A manual skip is not explained by the case data, so nobody downstream can tell whether Credit Check was not needed or was skipped.

Make the report meaningful

• Decide what "completed" means for a stage that was never entered: exclude never-entered stages from the duration denominator, or report them as not applicable rather than as zero or as outstanding.
• Capture the reason as case data (postpaid flag, port flag) at creation so the report can group by it rather than infer it.
• Check the interaction with SLAs: a stage SLA on a stage that is not entered never starts, which is expected - but a case-level or overall-install SLA keeps ticking through the alternate path. Confirm the alternate paths have their own committed times, or the fast path will be judged against the slow path's clock.

Diagnosis

A child case has its own lifecycle. Creating one gives the parent a view of the child's status; it does not make the parent wait, and nothing makes the parent react when the child resolves. The parent proceeds on the assumption it made at creation time, and the rejection only surfaces when a human notices - hence six days.

Options, in order

1. Don't use a child case. If approval is a step in the install process, model it as a process or a stage in the same case. Rejection is then an ordinary process outcome and there is nothing to miss.
2. Child case, synchronous wait. If it must be a child - separate team, separate SLA, own audit trail - have the parent park on the child and continue only when it resolves, and model the rejected outcome as a branch of that step. This is correct behaviorally but see the warning below.
3. Child case, asynchronous. If the parent must keep working while approval happens, then the dependency has to be explicit: the child notifies the parent on resolve (updates parent data, sets a flag the parent's process reacts to, or sends an event to the parent case), and the parent has a step that checks or receives that signal. Without an explicit signal, you have today's behavior.

The trap with synchronous waiting

Do not hold a case lock across a multi-day human approval. A pessimistic lock held while waiting blocks every other user, expires, and produces exactly the concurrent-save symptom in this same scenario. For long approvals, prefer option 3 with a real notification path, or park the parent outside the locked context.

Test

Run approved, rejected, withdrawn, and timed-out paths. Rejection is the path that was never tested, which is why it took six days to discover.

Most likely causes, in order

1. Locking is not pessimistic. The default is a case-level pessimistic lock: opening a case for processing locks it, other users are told it is locked or see it read-only, and the lock is released on submit or close. A silent overwrite means that default has been changed - optimistic locking, or locking disabled - so both submits are accepted and last writer wins.
2. One path bypasses the harness. A list-level action, a data transform run from a report, or an integration writing to the work class directly does not take a case lock. Two "users" saving may really be one user and one background writer.
3. Lock expiry. The first user's form stayed open past the lock timeout; their submit then succeeded after the lock had been released to someone else.

Choose, then implement

• Concurrent editing is rare and conflicts matter (claims, money): keep pessimistic locking. Set the lock timeout shorter than a realistic session, and handle "lock not acquired" with an explicit message and a read-only view rather than a retry loop.
• You cannot hold locks (long approvals, many contributors): use optimistic locking with conflict detection. Store a version or update timestamp on the case, compare it on submit, and if it has moved, reject the save and show the user what changed. Optimistic locking without conflict detection is precisely the silent overwrite you are seeing.

Also

Instrument it: log lock acquisition failures and rejected submits. If the overwrite is happening through a background writer, no amount of UI locking will fix it - that writer must update through a controlled path that respects the same version check.