When a request passes to another business area¶
A request can finish its review and then pass approved information to another business area. For example, an equipment request may finish its internal approval route before procurement begins its own work. The request reference identifies the Zerohive request; a receiving team's reference identifies the separate work created there.
Availability: the backend implements preparing the handoff, waiting for a result and recording a receiving reference and status. Delivery to a receiving service and a connected frontend have not been verified. The current request screens use examples. A configured destination, a preview status or a successful approval does not prove that another team received the request.
What happens at the end of the route¶
The handoff is automatic when the workflow reaches its completion boundary and its saved definition includes a handoff. It does not occur immediately when the requester submits the form. A route without a configured handoff can finish within Zerohive.
For a configured handoff, the system prepares information from the current request answers, records the intended destination and changes the request to a waiting state. The receiving integration must then handle that information and report a result. Registering a destination makes its name eligible for this process; registration alone does not install or verify a working integration.
The template owner decides which answers are passed across. A handoff with no selected field mappings passes the complete current answer object. With mappings, it selects the configured source fields and uses their destination field names. A missing source field is skipped. Template owners should check the exact information needed by the receiving team, including sensitive answers and required values, before introducing the request type. The handoff does not independently prove that the receiving system accepts those values.
Read request templates for template ownership and the request guide for submission and review. A handoff does not require the requester to submit a second copy of the request.
Understand the saved result¶
| Information | What it tells you | What it does not establish |
|---|---|---|
| Waiting for another business area | The workflow is waiting for an external action or handoff result. | That the receiving service has received or accepted the work. Some signing operations also use an external-wait state. |
| Receiving reference | The reference supplied when the handoff result was recorded. | A verified link, access to the receiving system or independent confirmation that its record exists. |
| Receiving status | The text supplied with that result, saved as a snapshot. | A continuously refreshed status or proof that the receiving work is finished. |
| Update time | When Zerohive recorded that result. | When the receiving team's underlying work happened or whether its status has changed since. |
| Completed Zerohive request | The local workflow has completed. | Completion of procurement, fulfillment or any other work owned by the receiving team. |
For example, a saved handoff result might say In procurement review and supply a procurement reference. The Zerohive workflow can then become completed while procurement review remains open. Treat the two outcomes separately when reporting progress.
The current result mechanism records one completion result. It is not an ongoing status-synchronization feature. A later, different receiving status cannot be treated as an ordinary refresh of an already completed workflow through that mechanism. The receiving integration and product owners must agree how later progress will be communicated.
If work appears to be waiting¶
Use the request's saved detail and history as described in the request guide. Keep the request reference, destination if shown, any receiving reference, the visible status, its update time and the approximate time the problem began. Check with the responsible team through your approved support channel before making another request.
| Situation | Appropriate follow-up |
|---|---|
| No receiving reference appears | Ask support to determine whether a handoff was prepared, delivered, accepted or still awaiting a result. Absence of a reference alone does not identify which step failed. |
| A receiving reference exists but its status seems old | Ask the receiving owner for the current position and compare it with the saved update time. Do not assume the snapshot refreshes automatically. |
| The screen or submission response times out | Refresh saved state and ask support to reconcile the result before repeating a consequential action. A timeout does not establish that delivery failed. |
| The destination is unavailable or not configured | Ask the template and integration owners to resolve the destination. Changing a template does not prove that an existing request was safely reprocessed. |
| The request was cancelled after handoff began | Ask the receiving owner whether separate work needs to be stopped. Local cancellation does not reverse work already delivered elsewhere. |
| Information or references disagree | Preserve both references and the observed times for support. Do not create a replacement request or manually claim completion to make the displays agree. |
This guide does not describe a user-facing Report handoff result or Retry handoff button: a connected, verified journey for those actions has not been established. Support should use the owning service's approved procedures after checking the saved state and receiving evidence. Share sensitive answers only when needed through an authorized channel.
Responsibilities before rollout¶
The business process owner should identify who owns the receiving work, what the handoff means, which information is necessary and what users should expect while waiting. Agree whether the reported result means intake, acceptance or fulfillment; the saved status text alone does not enforce that business meaning.
The template and integration owners must establish a working destination, access controls, correct field mapping, result reporting and a safe response to repeated delivery or uncertain outcomes. Support needs a way to correlate both references and escalate a stalled request. These responsibilities remain necessary even if the template can be published.
Managers and executives should distinguish completed internal approval, recorded handoff and completed receiving work in their reporting. Neither handoff activity counts nor a completed local request establishes service quality, fulfillment, savings or a guaranteed delivery time. End-to-end rollout, recovery and reader walkthroughs remain open verification work.