Parent–Child Service Request Workflow: Closure Gates

A meeting-room upgrade needs facilities work, network configuration, and equipment installation. Each team finishes its own assignment, yet the room still cannot host a call. The missing control is not another task list: it is a decision about when several completed parts constitute one accepted outcome.

A parent–child service request workflow keeps one accountable request for the promised result and linked child records for separately owned deliverables. This article provides a recommended operating design for internal service operations. Its states and review targets are design choices, not software defaults or contractual service levels.

Choose a hierarchy only when the outcome needs one

Use a parent when the requester expects one combined result but different teams must accept and complete distinct work. Each child needs a bounded output, an owner, an acceptance check, and a relationship to that result. A checklist may be sufficient when one owner performs all the work and no separate handoff or evidence is necessary.

• Same outcome, repeated report: assess a duplicate rather than launch another child assignment.
• Several deliverables needed for one result: retain a parent and identify the required children.
• Unrelated new outcome: create separate intake with its own authorization, not a child added for convenience.
• Information-only relationship: link related records without making either one’s completion depend on the other.

The distinction matters because platforms implement relationships differently. Zoho Desk’s parent–child documentation describes configurable closure rules in both directions. A relationship alone therefore does not establish which closure behavior is appropriate for your operation. Test your selected configuration rather than treating the word “child” as a control.

For repeated reports of the same work, use the separate duplicate service request workflow rather than dividing one obligation into competing execution records.

Keep the parent promise and child deliverables separate

The parent owner is accountable for the combined outcome, requester communication, scope decisions, and final acceptance. Child owners are accountable for their deliverables and evidence. A named verifier checks that the assembled result meets the parent promise. For higher-consequence work, assign a verifier with the appropriate independence under local policy.

Record the parent’s original request ID, requester, promised outcome, acceptance conditions, priority, original received time, current target, coordinator, and scope version. Maintain a child register with a unique child ID, parent reference, deliverable, required-or-optional designation, owner, prerequisites, acceptance criteria, current state, next action, and evidence reference.

Do not copy every parent detail into every child. Share only the context and records that the receiving role is authorized to see. Parent visibility must not automatically expose restricted attachments from another team’s work.

Use two state models and one closure gate

Keep parent progress distinct from child progress. One child can be blocked while another is ready for verification. A single parent label cannot replace the child register.

Use child states such as Proposed, Accepted for delivery, In progress, Submitted, Accepted, and Cancelled with authorization. Track blocking reason, recovery owner, and review time alongside those states. “Submitted” means the delivery owner supplied an output; “Accepted” means the named receiver checked it. A completed child is not proof that the combined outcome works.

Recommended closure rule: the current approved child register has no unresolved required deliverable; each required child has accepted evidence or an authorized scope disposition; the integrated acceptance test passes; and no unresolved change can invalidate those checks. Recheck this rule at closure, not only when the request first enters Integration review.

A cancelled child should not quietly satisfy an acceptance gate. If its deliverable is no longer required, retain the authorized scope change and why the parent outcome remains valid. If it is still required, cancellation leaves a delivery gap.

Make each child handoff an accepted commitment

The coordinator sends the proposed child assignment only after the parent owner approves the deliverable boundary. The packet contains the parent reference and scope version, required output, relevant context, prerequisites, expected timing, acceptance test, receiver, and escalation contact.

The receiving team accepts the deliverable, names its delivery owner, confirms the next action, and identifies any dependency or capacity constraint. Until that acceptance is recorded, the coordinator owns the pending handoff. A notification, queue placement, or historical assignee is not an accepted commitment.

If a prerequisite child must finish first, name the specific usable output rather than merely linking its ID. The receiving child may start only when the prerequisite evidence is accepted under the agreed rule. Independent children can run in parallel, but “parallel” must not mean every team guesses at unfinished upstream decisions.

Recover from failures without hiding unfinished work

Missing context or a rejected assignment

Detect this through intake validation or a receiver’s explicit rejection. Keep the child Proposed and the handoff pending. The coordinator obtains the missing information or asks the parent owner to resolve scope or capacity. Escalate at the locally agreed review point. Resume only when the receiver accepts the corrected packet; retain the rejection and revised scope reference.

An owner is unavailable or an external team is silent

The parent owner assigns a qualified backup or escalates to the service owner for a capacity decision. For external delivery, retain the provider reference, last confirmed state, next follow-up, and internal contact responsible for reconciliation. Keep the affected child blocked until its actual delivery state is known or an authorized alternative is accepted. Do not create a replacement assignment merely because an acknowledgment is late.

Evidence fails or two children conflict

The verifier records the failed criterion and evidence version. Return only the affected work to its owner; preserve unaffected accepted outputs. When one team’s change invalidates another’s result, the parent owner identifies every affected child and agrees a revised integration test. Keep the parent in Integration review or Delivery active until the conflict is resolved and retested.

A late child appears while closure is underway

Compare the new obligation with the approved parent scope. If it is required for the original outcome, reopen decomposition review and block closure. If it is new scope, route it through the authorized change or intake process. Record who decided and which scope version now governs the parent. A closure check against an older register is no longer sufficient.

A required child is cancelled or reopened

Require a parent-owner decision on the effect, rather than relying on automatic status propagation. Before parent closure, a reopened required child invalidates its accepted disposition until reassessed. After parent closure, evaluate whether the combined result has failed and use a controlled reopening route. Preserve the prior valid completion history instead of silently rewriting it.

If cancellation affects the entire outcome, use a service request cancellation workflow to reconcile active instructions and residual obligations. A parent status change alone does not prove every team stopped.

Walk through a room-readiness request

Illustrative scenario: the parent promise is a meeting room that can host the agreed video-call test. Facilities owns safe equipment mounting, IT owns connectivity, and audiovisual support owns the configured call equipment. The parent owner defines the integrated test before assigning these children.

Facilities supplies accepted mounting evidence. IT accepts its connectivity test. Audiovisual support submits a successful device check, but the integrated call has no room audio. The verifier records the failure; the parent remains in Integration review. Audiovisual support accepts the correction, checks its configuration against IT’s current settings, and supplies revised evidence. The verifier repeats the full call test, not just the isolated device check.

Only then does the parent owner recheck the current child register, accept the combined result, and communicate closure. If a second room is requested during the test, that is new intake or an approved scope change—not an unrecorded fourth child under the original commitment.

Measure outcomes without counting children as extra demand

• Demand: count parent requests and child assignments separately. One parent with three children is not four independent customer outcomes.
• Flow: measure parent receipt-to-acceptance time and child assignment-to-acceptance time as separate distributions. Keep original timestamps when splitting work.
• Queue health: review proposed children awaiting acceptance and submitted outputs awaiting verification, with age and responsible role.
• Capacity: show accepted active children by delivery team and the next constrained prerequisite; a small parent queue can hide a large execution load.
• Quality: track parents failing integration review and which previously accepted outputs needed correction.
• Reliability: track required children without owners, invalid parent references, late scope additions, and closure attempts blocked by incomplete evidence.

At an operating review, inspect recurring integration failures and long handoff waits. Improve the acceptance test or decomposition boundary where the pattern originates. Do not improve a completion metric by cancelling unfinished children or resetting their creation dates.

Where Workhint fits

The Workhint Workflow Engine describes configurable request steps, role-based approvals, and requirements for information or files before work advances. Those are relevant building blocks for owned handoffs and evidence gates.

Workhint’s workflow automation software solution also describes structured forms, conditional routing, stages, role-specific permissions, and event-based notifications. These support a discussion about coordinating multi-team service work. The pages do not establish native parent–child closure propagation, atomic cross-record checks, or a particular audit-retention guarantee. Validate those requirements in your configured system before relying on them; use an explicit coordinator review where a required guard is unavailable.

Build This in Workhint

Use the following as a requirements prompt, not a claim that every control is available without configuration:

Design a multi-team service request system with one parent outcome and uniquely linked child deliverables. Define requester, coordinator, parent owner, child delivery owner, verifier, backup, and service owner roles. Limit each role’s access to relevant records and evidence. Capture parent scope version, acceptance conditions, original received time, required children, dependencies, owner acceptance, review targets, and evidence versions. Use the parent and child states above. Require approval for scope changes and cancellation. Block parent closure until required child dispositions and the integrated test have been reviewed against current scope. Create tasks and notifications for pending handoffs, failed checks, unavailable owners, and overdue external responses. Provide views for unowned children, delivery load, blocked dependencies, and integration failures, with separate parent and child metrics. Retain decision and transition history. Identify which cross-record guards, reporting, and audit-history requirements need additional configuration or a manual control before launch.

FAQ

Should every task become a child request?

No. Use a child when the work needs its own accountable owner, acceptance condition, tracking, or handoff. Keep small actions inside the owning team’s checklist when separate records add no operating value.

Can the parent close when all children say Done?

Not under this recommended model until required evidence and the combined result have been accepted. A status label alone does not prove either test passed.

Does reopening a child automatically reopen the parent?

That depends on the configured platform and rules. Define the required parent review explicitly, test supported behavior, and retain a manual control if propagation is unavailable or inappropriate.