Dependencies and shared delivery¶
Project work often depends on another person's work. Several people may also contribute to one result. Zerohive has backend records for acknowledging a resolved dependency and naming the people involved in a shared delivery. These records explain responsibility and supporting proof; the work item still has its own progress, review and completion process.
Availability: This is a source-backed explanation of implemented backend capabilities. The inspected Final Screens show blocking and managing work, but a dedicated dependency-resolution or shared-delivery journey has not been verified. The frontend remains a preview. There are therefore no verified screen instructions here for submitting these records, and no claim that these actions are available in your environment. Continue using the execution guide for the intended work-item journey.
Understand the four different records¶
| Record or action | What it means | What it does not establish |
|---|---|---|
| Block a work item | Record why that item cannot proceed and put it into a blocked state | A relationship to another work item, an assigned resolution owner or an automatic release rule |
| Dependency relationship | Identify another work item on which this work depends | That either item is blocked, completed or approved |
| Resolve a dependency | Record who helped resolve an existing relationship, why it is considered resolved and a reference to proof | Automatic unblocking, completion or approval of either work item |
| Record shared delivery | Save a named group of project participants, an outcome and supporting references for one work item | Completion of the work item, acceptance of a deliverable, a formal approval or a contribution score |
For example, preparing a release may depend on an environment being ready. Recording that the environment issue was resolved explains that handoff. The release work still needs its own evidence and review. Likewise, naming two contributors to the release does not approve the release itself.
Record a blocker through the intended execution journey¶
The inspected Block backlog item design asks for a Block reason, offers Cancel, and confirms with Block item. Explain the condition that prevents progress in language the delivery team can act on. The execution guide covers blocking and restarting work, including the actual state limits.
The implemented blocking action records a reason. It does not save a separate resolution owner, target resolution date, impact assessment or release condition. The current blocking preview collects a reason and reports that it was not saved. It does not provide a connected dependency-resolution or shared-delivery action. A block reason also does not create a dependency relationship.
No ordinary user action for creating a dependency relationship was found in the inspected project operations. The backend resolution capability needs a relationship that already exists. If an expected dependency is missing, ask your project lead or support to investigate the supported setup; do not create a duplicate work item as a substitute.
Prepare a dependency resolution¶
The following is a preparation checklist for the capability, not a sequence of screen controls:
- Identify the work that depends on something else and the existing linked dependency. Confirm that both records belong to your workspace.
- Confirm the dependent work has an assigned owner. That owner or the owner of the linked work must attest the resolution, with permission to manage projects.
- Name at least one resolver. The supported resolver list is limited to those two assigned owners; people outside that set cannot be added merely because they helped informally. Name each person once. If the linked item's owner is making the attestation and is not also the dependent item's owner, include that person in the resolver list.
- Write a concise explanation of what changed and why the dependency is considered resolved.
- Provide a reference to the supporting proof. Check that the intended reviewers can access it through the appropriate authorized channel.
The current backend accepts a nonblank explanation and proof reference. It does not independently open the proof, evaluate its quality or require the linked work to be completed. The people making the attestation must establish that the statement is accurate. Do not put secrets or confidential document contents into a reference or explanation.
Completed or cancelled dependent work cannot have its dependency resolved through this action. Other supported work states can record a resolution; the item does not first have to be marked blocked. If work is already completed, agree with the project lead whether a correction or the separate reopening process is appropriate. Reopening changes other delivery facts, so it should not be used casually to bypass a restriction.
What changes after a resolution¶
The dependency saves the dependent item's current owner, the named resolvers, the explanation, the proof reference and the resolution time. A later accepted resolution of the same dependency can replace those saved details. It is not an append-only history of every attestation.
The operation leaves the item's state and block reason unchanged. It does not start either item, reevaluate completion requirements, accept a deliverable or approve a milestone. The team must separately confirm that work can proceed and use the appropriate execution action.
The current project dependency summary shows the linked work and its state. Its “Dependency complete” or “Unblock dependency” wording comes from whether that linked work is completed, rather than whether a resolution attestation was saved. It does not show the saved resolver list, explanation, proof or resolution time. Do not use that summary alone to confirm a successful resolution or diagnose a failed save.
If the result is uncertain, retain the project and item references, the time and any returned receipt, and ask support to confirm the recorded outcome before submitting a new request. Repeating the action with different proof can overwrite details and has unresolved contribution-record consistency implications.
Prepare a shared-delivery record¶
Shared delivery names who contributed to a particular work item within a project. Prepare:
- The project and the work item belonging to that project.
- A list of distinct people already recorded as project participants, including the person making the attestation. At least one person is required; the implementation does not require two or more.
- Each person's supported participation description: the project's owner, or a named co-contributor. The project-owner description is limited to the persisted project owner. A reviewer-only role is not supported by this action.
- A clear outcome, a proof reference and a stable reference identifying the work or result being described.
The attesting person needs project-management permission and must appear in the participant list. They do not have to be the work item's assignee or the project's owner if they are an eligible named co-contributor. The current action checks saved project participation; it does not collect each participant's confirmation or verify current organizational assignments.
The backend creates a separate delivery record with its own identity and time. A new accepted request can create another record for the same project and work item; the work reference is not a duplicate-prevention guarantee. If the response is unclear, ask support to check the original request before recording the same delivery again.
Interpret the outcome correctly¶
A shared-delivery record can be made while the work item is still planned. The action does not require an already completed item or an accepted deliverable, does not perform a review, and does not change the item's state. An outcome supplied by the attestor should therefore be assessed alongside the actual item, evidence and approval records.
The inspected project read operations do not provide a dedicated shared-delivery history or detail view. A receipt confirms the identity returned by the operation; it is not a substitute for a verified readback or proof that downstream reporting has processed the record.
Both dependency resolution and shared delivery produce contribution evidence for further processing. Neither action promises recognition, a score increase, a particular dashboard update or a financial outcome. Dependency timing in that evidence is measured from when the relationship was created to when it was resolved. It is not a measured sum of the time the work item actually spent blocked, and it must not be presented as hours saved or individual productivity.
Responsibilities and recovery¶
Delivery owners should agree what constitutes useful proof, check that named people are correct and keep delivery-state changes separate from attestations. Managers should verify the actual work and approval before treating an attested outcome as accepted delivery. Executives should use these records as context for a discussion, alongside verified outcomes; neither a participant count nor dependency duration is an independently validated performance measure.
Workspace administrators manage permissions and help correct missing participation or assignment through supported operations. Membership alone does not grant management permission, and management permission alone does not satisfy the owner or participant checks described above.
For support, provide the workspace, project and work references, the intended action, the time, the exact error and any receipt. Do not publish private proof in a support forum or documentation review. A missing owner, an ineligible resolver, a person absent from the saved project participants, an unsupported participation description or a closed dependent item needs investigation or correction of the relevant record. An uncertain save needs outcome confirmation before a fresh submission.
No separate fee, usage quota, notification guarantee or delivery-time promise is established by these two operations. Environment availability and wider workspace controls remain separate concerns. Continue with execution and review, deliverables and formal governance, or repository evidence according to the next action you need.