Source: [Jira and Confluence: From a Business Question to a Working Feature](https://treenodes.com/articles/jira-confluence-business-question-to-working-feature/)

This Markdown version is generated from the public page. Visit the source for interactive examples and full-size visuals.

[All writing](https://treenodes.com/articles/)

Published 16 September 2026 · Systems design · 25 min read

# Jira and Confluence: From a Business Question to a Working Feature

Follow the work. Make its logic visible. Three scenarios connect a map of current operations to shared decisions, scoped Jira work and validation.

Written by [Nermien Barakat](https://treenodes.com/articles/by/nermien-barakat/)  · Systems & Applied AI Architect

![A female architect observes a silver-haired coordinator and a technician, maps the work and reviews it with them. The journey is Observe, Understand, Map, Agree, Deliver and Check. Board notes show an optional Initiative above Epic, Story or Task, and Subtask; automation is shown separately.](https://treenodes.com/assets/articles/jira-confluence-business-question-to-working-feature-hero-treenodes.webp?v=e270aa1035e6)

Observe the real operation, make its logic visible and check the proposed change with the people doing the work. Conceptual artwork with fictional scenes.

## Follow the work. Make its logic visible.

“Can someone come tomorrow?” Before that question becomes a booking feature, a coordinator must understand the job, find the right person and decide whether the team can keep the promise.

Start with the work in real life: who acts, what information they need, where work waits and what happens when the usual path breaks. Map those handoffs with the people doing the work, including informal checks and exceptions.

Keep three things distinct: **today’s operation**, **the proposed design** and **the agreed change**. A map helps the team discuss them; it does not prove the process is complete.

Use **Confluence for shared context and decision rationale**, and **Jira for scoped work, owners, dependencies and acceptance criteria**. This is a working convention to agree with your team. Dan Radigan’s [product requirements guide](https://www.atlassian.com/agile/product-management/requirements) provides the starting point; the fictional journeys below show how to carry a decision through delivery and a later change.

**Explore the diagrams:** each scenario has its own operation maps. Jump to [inputs → f → outputs](https://treenodes.com/articles/jira-confluence-business-question-to-working-feature/#jcp-function-title), the [complete booking process and database](https://treenodes.com/articles/jira-confluence-business-question-to-working-feature/#jcp-process-title), or the [Jira delivery hierarchy](https://treenodes.com/articles/jira-confluence-business-question-to-working-feature/#make-the-links-useful).

## Choose your journey

Choose one scenario and follow its six steps. Use “Show all scenarios” to compare them.

Fictional scenarios and records. Expected results are proposed checks, not reported outcomes.

Scenario 1 · Fictional worked example

### Promise a visit the team can actually deliver

#### 01 Observe the operation

> The heating has stopped working. Can someone come tomorrow?

A service coordinator sees an empty slot and considers offering it to the customer. The slot looks available, but that alone says nothing about the technician’s skills, travel time or the time needed at the property.

The request to ‘add appointment booking’ therefore starts with a business promise: send a suitably qualified person at a time the team can honour. This fictional example focuses on scheduling; parts procurement and emergency triage remain outside the first delivery.

Start with the operation

**Current operation**

Current operation: Receive the request → Check the shared diary → Call the technician → Confirm with the customer → Record the appointment.

In this fictional operation, a phone call supplies information the calendar does not contain. Before changing the process, ask the coordinator and technician what they check, where they wait and what happens if the answer changes.

#### 02 Understand the question

How can a coordinator confirm a visit with the right skills and enough time to complete the work?

| Record | What it says |
| --- | --- |
| Current operating baseline | A coordinator checks a shared calendar, phones a technician and confirms the appointment manually. Travel allowances are added by judgement. |
| Proposed first delivery | Offer a visit only when one qualified technician has time for the planned work and its travel allowance. Recheck availability when the coordinator confirms it. |
| Assumption to confirm | One technician can carry out every job included in the first release. The service manager must confirm this scope before the scheduling rule is committed. |

#### 03 Map the proposed design

Business workflow

**Original design**

#### Original design

Original design: Describe the job → Check one technician → Confirm the visit → Assign the technician → Record the outcome.

#### Proposed change · VIS-CHG-02

Proposed change: Classify crew size → Check the whole crew → Confirm one shared slot → Assign both people → Record the outcome.

Follow the original design, then explore VIS-CHG-02. Arrows illustrate the business sequence; they do not execute Jira actions.

#### 04 Agree the decision and reason

Confluence · decision record `VIS-DEC-01`

##### Recheck qualifications and availability at confirmation; browsing does not reserve time.

Accepted for implementation; not released

**Decision owner:** Service manager

**Options considered:**

1.  Let the coordinator book any empty slot and resolve conflicts afterwards.
2.  Hold a slot as soon as someone opens it.
3.  Check qualifications and the full time block when the coordinator confirms.

**Reason:** An appointment is a commitment. A calendar view may have become out of date while the coordinator spoke to the customer.

**Tradeoff:** A slot can disappear before confirmation. Keep the entered details and explain why another time is needed.

#### 05 Deliver through scoped Jira work

**Decision reference:** `VIS-DEC-01`

Jira · example story `VIS-12`

##### Confirm an achievable appointment

As a coordinator, I want to confirm a qualified technician for the complete visit time so that I can give the customer a dependable appointment.

**Owner:** Scheduling developer; review with the service coordinator

**Scope:** Confirm one technician against the recorded job requirements, work duration and travel allowance. Store a confirmation or explain the conflict.

###### Acceptance criteria

1.  A technician with the required qualification and a clear work-and-travel block can be assigned.
2.  A technician without the required qualification is rejected, even if the calendar is empty.
3.  If another appointment consumes the block before confirmation, this attempt is refused and the customer details remain available.
4.  The confirmed record identifies the job, technician, visit time and confirming coordinator.

**Resolve before implementation:** Who maintains job durations and travel allowances, and when must those estimates be reviewed? The service manager owns this decision.

##### A small delivery map

| Work | Why it exists | Owner |
| --- | --- | --- |
| VIS-11 · Describe the visit | Capture the skill, duration and travel inputs used to assess a slot. | Requirements analyst |
| VIS-12 · Confirm the appointment | Apply VIS-DEC-01 at the moment the commitment is made. | Scheduling developer |
| VIS-13 · Communicate the confirmation | Give the coordinator an accurate customer-facing summary after confirmation succeeds. | Communications developer |

An epic can group VIS-11, VIS-12 and VIS-13 as the visit-booking delivery. VIS-12 also needs an agreed qualification-and-availability contract before its implementation can be validated. That dependency is different from membership of the epic. Identity, access and reliable availability data form a supporting foundation; proposed module boundaries remain provisional.

#### 06 Check the impact of a change

VIS-CHG-02 · Proposed; requires agreement

##### Some visits need two technicians

The service manager identifies a category of installation that requires a qualified lead and a second technician. The original one-person assumption no longer covers the intended scope.

**Decision owner:** Service manager

**Still to agree:** Agree which jobs need two people, the qualification required for each role, and whether already-confirmed visits need review. Do not silently apply this proposal to every booking.

###### Proposed updates if the change is accepted

| Affected record | Update to review | Responsible owner |
| --- | --- | --- |
| Confluence requirements and VIS-DEC-01 | Record the crew rule and its reason after acceptance; preserve the earlier one-person decision and rationale. | Requirements analyst |
| VIS-11 and VIS-12 | Capture crew size, validate both roles and reserve a shared slot for both people as one confirmation. | Scheduling developer |
| VIS-13 and affected future visits | Revise the confirmation summary and identify bookings that need a coordinator’s review. | Service coordinator |
| Validation record VIS-VAL-02 | Add paired availability and partial-failure checks. Record results and the tested version only after running them. | Validation owner |

##### Validate the proposed change

Proposed checks · not executed

**Example input:** Use a fresh fictional fixture for each check: a two-person job needs a qualified lead plus an assistant for 10:00–12:00, including the agreed travel allowance. Alex is a qualified lead and is free. Sam is an assistant but is busy from 11:00–12:00. Lee is an assistant and is free for the whole block. Assume the proposed crew rule has been accepted for these checks.

| Try this | Expected result |
| --- | --- |
| Try Alex and Sam together. | Refuse confirmation: the shared block is not available. Create no confirmed assignment for either person. |
| Try Alex and Lee together. | Confirm both people for the same visit if their availability is unchanged at confirmation. |
| Make Lee unavailable just before the first confirmation attempt, then try Alex and Lee. | Refuse the complete booking, keep the entered details and leave no partial confirmation. |

**Useful variation:** Start from an existing one-person appointment. Check that the new proposal flags it for review where relevant, rather than silently adding an unconfirmed assistant.

Record the actual result, evidence, reviewer and tested version when these checks run. Evidence is **pending**.

An appointment is a promise about people and time. Trace the rule behind that promise, not just the calendar screen.

Scenario 2 · Fictional worked example

### When capacity changes, which start dates need review?

#### 01 Observe the operation

> We need a project plan that tells us when the next piece of work can start.

A date can look more certain than its assumptions. Six days of preparation produce different start dates for the next task when an engineer has five available days each week rather than three.

This fictional planning feature uses invented inputs, decisions and references. Its capacity figures are not measured productivity. The feature has not been implemented or tested.

Start with the operation

**Current operation**

Current operation: List the remaining work → Ask about availability → Adjust spreadsheet dates → Discuss affected promises → Record the agreed plan.

In this fictional operation, the spreadsheet records the plan, while conversations establish capacity and commitments. Check who supplies each input and who must agree a changed date before treating the spreadsheet as the whole process.

#### 02 Understand the question

How can a project coordinator propose a start date that reflects the assigned person's capacity and earlier commitments?

| Record | What it says |
| --- | --- |
| Current operating baseline | A spreadsheet records estimates and dates. The coordinator checks availability, adjusts the plan manually and tells stakeholders when a promise changes. |
| Proposed first delivery | The accepted first design calculates an earliest start from remaining effort, work order and available days. The coordinator reviews suggestions before recording commitments. The spreadsheet remains the operating baseline. |
| Assumption to confirm | ASSUM-P1: the engineer has five full days available, Monday to Friday, with no other commitments or absences. The coordinator must confirm this input. |

#### 03 Map the proposed design

Business workflow

**Original design**

#### Original design

Original design: Record five available days → Keep effort and work order → Calculate available workdays → Suggest the next start → Review the commitment.

#### Proposed change · CHG-P2

Proposed change: Propose three available days → Keep effort and work order → Recalculate remaining work → Flag the affected start → Agree a revised commitment.

Follow the original design, then explore CHG-P2. Arrows illustrate the business sequence; they do not execute Jira actions.

#### 04 Agree the decision and reason

Confluence · decision record `DEC-P1`

##### Suggest the earliest start from capacity and ordered work; record the committed date separately.

Accepted for implementation; not released

**Decision owner:** Project coordinator

**Options considered:**

1.  Continue calculating dates manually and record the assumptions beside each promise.
2.  Calculate from recorded capacity and effort, then require the coordinator to review the proposed date.
3.  Automatically replace every committed date whenever an estimate or capacity value changes.

**Reason:** A capacity calculation informs a promise, but a revised promise also needs discussion with the people relying on it.

**Tradeoff:** A coordinator must review flagged differences, so the plan needs a visible queue of commitments awaiting attention.

#### 05 Deliver through scoped Jira work

**Decision reference:** `DEC-P1`

Jira · example story `PLAN-12`

##### Suggest a start date from capacity

As a project coordinator, I want a proposed start based on remaining work and available days so I can make a realistic commitment.

**Owner:** Planning developer

**Scope:** Calculate the next task's earliest start for one person working through an agreed sequence. Display the inputs and keep the suggestion separate from the commitment.

###### Acceptance criteria

1.  The calculation consumes remaining effort only on the person's recorded available days.
2.  The next task cannot start before the preceding task's remaining effort is allocated.
3.  Changing an input recalculates the suggestion and identifies a committed start that no longer fits.
4.  Recalculation leaves the existing commitment unchanged until the coordinator records a reviewed revision.
5.  The reviewer can see the capacity, remaining effort and sequence used for the suggestion.

**Resolve before implementation:** How should partial days, holidays and urgent interruptions be represented? Agree these rules before extending the whole-day example.

##### A small delivery map

| Work | Why it exists | Owner |
| --- | --- | --- |
| PLAN-11 · Record planning inputs | Capacity and remaining effort need explicit owners and visible assumptions. | Planning analyst |
| PLAN-12 · Suggest the next start | DEC-P1 separates a calculated suggestion from a reviewed commitment. | Planning developer |
| PLAN-13 · Review changed commitments | The coordinator needs to record the decision and notify affected stakeholders. | Delivery developer |

One parent can group these stories into the planning increment. PLAN-12 also needs validated capacity inputs from PLAN-11: a dependency naming a required outcome. Sharing a parent says the stories belong to the same delivery; it does not describe that dependency.

#### 06 Check the impact of a change

CHG-P2 · Proposed; requires agreement

##### Reduce available capacity from five days to three

The engineer is proposed for another responsibility on Thursdays and Fridays, challenging ASSUM-P1.

**Decision owner:** Project coordinator

**Still to agree:** Agree the effective week, remaining effort and promises to revise. These are proposed impacts, not completed changes.

###### Proposed updates if the change is accepted

| Affected record | Update to review | Responsible owner |
| --- | --- | --- |
| Requirements page / ASSUM-P1 | Record the proposed availability and its effective period; retain the previous assumption and reason. | Planning analyst |
| PLAN-11 | Review whether capacity can change by period without overwriting earlier planning inputs. | Planning analyst |
| PLAN-12 and PLAN-13 | Recalculate remaining work and identify commitments needing review after approval. | Planning and delivery developers |
| Validation record | Add the changed-capacity fixture and leave observed evidence pending until the checks run. | Validation owner |

##### Validate the proposed change

Proposed checks · not executed

**Example input:** Invented fixture: preparation needs six remaining days; the following task needs one. Start Monday, week 1, with no holidays or parallel assignments. These are expected checks, not reported results.

| Try this | Expected result |
| --- | --- |
| Use five available days, Monday to Friday. | Preparation finishes Monday of week 2; the next task can start Tuesday. |
| Propose three available days, Monday to Wednesday, effective from week 1. | Preparation occupies both weeks; the next task's earliest available day becomes Monday of week 3. |
| Compare that suggestion with a committed Tuesday start in week 2. | The commitment is flagged for review and retained until the coordinator agrees a revision. |

**Useful variation:** Apply the reduction after two days of preparation are complete. Verify that only remaining effort moves, and ask who confirms that progress.

Record the actual result, evidence, reviewer and tested version when these checks run. Evidence is **pending**.

A useful plan preserves the assumptions behind a date and gives someone responsibility for reconsidering the promise when those assumptions change.

Scenario 3 · Fictional worked example

### Does completing the checklist mean the customer is ready?

#### 01 Observe the operation

> We need an onboarding checklist so customers can start using the service.

A completed form, an approved role and an enabled account are different facts. One checklist tick can make a customer look ready while an important decision still awaits its owner.

This fictional customer portal uses invented roles, references and policies. No account is created. Its acceptance checks describe expected behaviour, not observed results.

Start with the operation

**Current operation**

Current operation: Collect details by email → Ask the sponsor to approve → Wait for the decision → Administrator enables access → Update the readiness list.

In this fictional operation, email carries an approval between people before access is enabled. Check whose decision is authoritative, how a changed role is handled and what the coordinator does when approval is delayed.

#### 02 Understand the question

How can an onboarding coordinator tell whether a named customer user has the agreed access and can begin work?

| Record | What it says |
| --- | --- |
| Current operating baseline | The coordinator collects details by email. A customer sponsor approves the role, an administrator enables the account, and a separate checklist records readiness. |
| Proposed first delivery | The accepted first design records role approval and account activation, then shows readiness. Staff can prepare an account before approval but cannot enable it. The email process remains current. |
| Assumption to confirm | ASSUM-O1: sponsor approval of the user and role authorises portal access. The operations owner must confirm this policy before delivery. |

#### 03 Map the proposed design

Business workflow

**Original design**

#### Original design

Original design: Collect user and role → Prepare account during review → Verify sponsor approval → Enable approved access → Confirm onboarding readiness.

#### Proposed change · CHG-O2

Proposed change: Collect user and role → Prepare account during review → Verify sponsor and security approval → Enable jointly approved access → Confirm revised readiness.

Follow the original design, then explore CHG-O2. Arrows illustrate the business sequence; they do not execute Jira actions.

#### 04 Agree the decision and reason

Confluence · decision record `DEC-O1`

##### Keep role approval, access activation and onboarding readiness as separate recorded facts.

Accepted for implementation; not released

**Decision owner:** Onboarding operations lead

**Options considered:**

1.  Keep approvals in email and link each checklist entry to the supporting message.
2.  Record explicit approval for the user and role, then let an administrator enable access.
3.  Enable access automatically when the coordinator marks the onboarding checklist complete.

**Reason:** Finishing administrative tasks should not silently supply approval to grant access.

**Tradeoff:** The coordinator must pursue pending approval even when preparation is complete.

#### 05 Deliver through scoped Jira work

**Decision reference:** `DEC-O1`

Jira · example story `ONB-12`

##### Enable access for an approved role

As an administrator, I want to enable only the approved role for a named user so access matches the decision.

**Owner:** Access developer

**Scope:** Check user and role approval before enabling an account. Record the outcome for the coordinator.

###### Acceptance criteria

1.  An authorised administrator can enable the named user only when sponsor approval exists for the currently requested role.
2.  Pending or refused approval leaves the account disabled and explains what decision is outstanding.
3.  Changing the requested role before activation invalidates the earlier approval for activation purposes and requests a new decision.
4.  Successful activation records the user, enabled role, administrator and time; an unsuccessful attempt does not mark access enabled.
5.  Completing the preparation checklist does not bypass the approval check.

**Resolve before implementation:** Who can change an active role, and does that suspend access? Decide that policy before adding the behaviour.

##### A small delivery map

| Work | Why it exists | Owner |
| --- | --- | --- |
| ONB-11 · Collect details and role approval | The administrator needs an approval tied to the correct user and requested role. | Onboarding developer |
| ONB-12 · Enable approved access | DEC-O1 requires activation to check recorded authority rather than checklist completion. | Access developer |
| ONB-13 · Explain onboarding readiness | The coordinator needs to distinguish completed preparation, pending decisions and enabled access. | Experience developer |

One parent groups the onboarding stories by delivery scope. ONB-12 also depends on ONB-11 supplying approval for the current role. That dependency names required information; it neither makes one story the other's parent nor requires all their development work to happen sequentially.

#### 06 Check the impact of a change

CHG-O2 · Proposed; requires agreement

##### Require security approval before access is enabled

The security team proposes an additional check for every new customer portal user, challenging ASSUM-O1.

**Decision owner:** Onboarding operations lead with the security lead

**Still to agree:** Agree approval authority and scope, including changed roles and existing accounts. These are proposed updates if the policy is accepted, not completed implementation.

###### Proposed updates if the change is accepted

| Affected record | Update to review | Responsible owner |
| --- | --- | --- |
| Requirements page / ASSUM-O1 | Record both approval responsibilities and the revised readiness rule, preserving the reason for the earlier design. | Product owner |
| ONB-11 and new ONB-14 | Add a security-review task tied to the same named user and role as the sponsor decision. | Onboarding developer |
| ONB-12 | Require both current approvals before activation; identify which decision is missing or refused. | Access developer |
| ONB-13 and validation record | Show security review separately and check that readiness stays incomplete while access is disabled. | Experience developer and validation owner |

##### Validate the proposed change

Proposed checks · not executed

**Example input:** Fresh fictional fixture for each check: U-01 requests Viewer. Preparation and sponsor approval are complete; access is disabled. Assume CHG-O2 requires both approvals for this user and role. Evidence is pending.

| Try this | Expected result |
| --- | --- |
| Attempt activation while security approval is pending. | Access remains disabled; the screen identifies the outstanding security decision and onboarding is not ready. |
| Record security approval for U-01 and Viewer, then activate successfully. | The recorded role is enabled and the readiness view reflects that result, with activation evidence available. |
| Record both Viewer approvals, then request Administrator before activation. | Existing approvals do not authorise Administrator access; the changed role needs fresh decisions. |

**Useful variation:** Refuse security approval after sponsor approval. Trace the explanation to the coordinator and identify who owns the next customer-facing action.

Record the actual result, evidence, reviewer and tested version when these checks run. Evidence is **pending**.

Readiness depends on recorded approvals and actions with explicit owners. A finished checklist is only part of that evidence.

## Delivery hierarchy and useful links

Use a few meaningful links between decisions and delivery work. Avoid copying the same specification into several records.

The delivery hierarchy is **optional Initiative → Epic → Story / Task → Subtask**. Story and Task normally share the same standard level; a task is not automatically a child of a story. An administrator can configure an initiative above epic on Jira Cloud Premium or Enterprise, across company-managed spaces. Check your site’s setup. [Default levels](https://support.atlassian.com/jira-cloud-administration/docs/what-are-issue-types/) · [Custom hierarchy](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/).

Technician visits · first design · one-technician scope

### Give each level a clear purpose

The hierarchy breaks down the delivery scope. It does not describe the order in which the application runs.

Initiative · optional configured level

#### Make field visits dependable

Epic

#### Visit booking

Story and Task: the same level, both children of this epic

Story · VIS-12

#### Confirm an achievable appointment

Proposed subtasks of VIS-12

-   Subtask**Implement confirmation checks**
-   Subtask**Check competing-booking outcomes**

Task · illustrative sibling

#### Review duration and travel inputs

This task belongs to the epic alongside the story. The subtasks shown belong to VIS-12.

**What does each level contribute?**

**Initiative:** a broader outcome that can include several epics. **Epic:** the visit-booking delivery. **Story VIS-12:** confirm one qualified technician for the complete work-and-travel block. **Task:** agree who maintains duration and travel inputs. **Subtasks:** smaller pieces of the story's implementation and checking.

Optional automation · unconfigured illustration

#### Prompt a human review

1.  Trigger**Work moves to review**
2.  Conditions**Decision-reference field is filled; reviewer is assigned**
3.  Actions**Notify the reviewer**

This suggested rule would need configuration and testing. A filled reference field does not establish that the decision is correct, enforced or fully implemented.

Illustrative work breakdown for the one-technician scope. The later two-technician change remains proposed. Parent–child relationships express scope; dependency links describe work that relies on other work.

**Automation: trigger → conditions → actions.** The illustrated rule prompts a review; it needs configuration and testing. Check the actor’s permissions and your automation allowance before enabling it. [Automation steps](https://support.atlassian.com/cloud-automation/docs/what-are-automation-rules/) · [Actor permissions](https://support.atlassian.com/automation/kb/automation-rule-actor-vs-automation-rule-owner/) · [Usage guidance](https://support.atlassian.com/cloud-automation/docs/how-is-my-usage-calculated/).

1.  **Display the work in Confluence.** With Jira connected, type `/jira` in the editor and choose **Jira work items**. Search with filters or JQL, then insert the results. For a single item, paste its Jira URL. [Display instructions](https://support.atlassian.com/confluence-cloud/docs/insert-the-jira-issues-macro/).
2.  **Give Jira a route back to the context.** For a parent-level work item in a connected, company-managed space—an epic by default—the documented route is **\+ → Page → Link page**. This is not a universal menu path for stories or team-managed spaces. In each story, include the relevant Confluence context URL and decision reference. [Linking instructions](https://support.atlassian.com/jira-software-cloud/docs/link-a-confluence-page-to-an-epic/).
3.  **Give the relationship a meaning.** Parent-child describes the breakdown of work. A *blocks / is blocked by* link expresses a dependency. [Hierarchy](https://support.atlassian.com/jira-cloud-administration/docs/what-are-issue-types/) · [Work item links](https://support.atlassian.com/jira-software-cloud/docs/link-issues/).
4.  **Check access.** Work-item linking must be enabled and the user needs the relevant permission. Team-managed permissions call this *Link any work item*; cross-space linking also needs it in the target space. Check that intended readers can open the linked records. [Configuration](https://support.atlassian.com/jira-cloud-administration/docs/configure-issue-linking/) · [Team-managed permissions](https://support.atlassian.com/jira-software-cloud/docs/next-gen-permissions/).

A link helps someone find the reason. It does not enforce the decision, update every affected record or prove implementation completeness. Record who reviews the impact and who updates the page, stories and validation evidence.

Jira and Confluence linking guidance was checked on 15 September 2026; hierarchy, automation and engineering references were checked on 16 September 2026. These instructions and the fictional validation checks were not executed in a connected Jira or Confluence environment for this article.

## From inputs to the database

Return to technician visits. **VIS-CHG-02 proposes a qualified lead and an assistant for one shared time block.** These diagrams show a possible application design after approval, implementation, validation and release. The change remains proposed; no implementation or successful test is claimed.

One operation · inputs → f → outputs

### Turn a request into an accountable result

#### Inputs

**Request**

Job, crew, time block, acting user and request ID.

**Current records**

Requirements, skills, availability and existing bookings.

**Deployed rules**

Implemented crew, qualification, overlap and access rules.

#### Evaluate and safely record

1.  Validate the request and authority.
2.  Check current facts against the rules.
3.  Reserve the complete crew together.
4.  Record and return the outcome.

#### Outputs

**Result for the coordinator**

A confirmed visit, or a clear refusal reason.

**Changed stored state**

Booking + complete crew + request outcome + notification work.

**When refused**

No partial booking. Keep the request details for review.

`(result, new state) = f(request, current records, deployed rules)`

**f**

 represents the whole application operation, including coordination with stored records. It is a conceptual model, not a pure calculation. If a response is lost, the caller must establish the recorded outcome.

The application applies released rules to operational records. Accepting a decision in Confluence does not change the running system.

Technician visits · proposed VIS-CHG-02 design

### One request, one recorded outcome

Explore the two-person booking design. It imagines future operation after approval, implementation, validation and release.

Select a node to follow its connections and open its explanation below.

Swipe or scroll horizontally to explore the map. Every step is also explained below.

Diagram: Explore system responsibilities

Application flow Operational handoff Future change after release

The notification branch is independent. A saved booking can lead to a visit even when notification delivery fails.

**Visit request — what enters**

The proposed request identifies the job, qualified lead and assistant, one complete work-and-travel block, acting user and a stable request ID. That ID identifies one booking attempt, including retries.

**Booking API — establish authority**

Authenticate the caller, check their permission and validate the fields before acting or exposing a saved outcome. If the request ID already exists, establish its recorded outcome rather than starting another reservation. Invalid or unauthorised requests do not confirm a booking.

**Confirm visit — apply the rule safely**

Check both roles, qualifications and the complete shared time block against current records. Recheck the relevant facts under suitable locking, constraints or isolation, and enforce request-ID uniqueness inside the transaction. Save the booking, both reservations, request outcome and notification request together; report confirmation only after the commit succeeds.

A transaction alone does not prevent two requests accepting the same slot. If a competing booking wins, leave no partial crew reservation. A concurrent retry retrieves the winning attempt’s outcome; reject reuse of its ID with different booking details.

**Database — read facts, commit the whole result**

Conceptual records include jobs and required roles, people and skills, working availability, bookings and request outcomes. The successful transaction writes both crew reservations, the booking, its request outcome and an outbox record: saved work for a separate notification sender.

Notification attempts and actual visit outcomes are updated afterwards. This is a conceptual data model, not a selected database product or prescribed table schema.

**Recorded result — distinguish refusal from uncertainty**

Return the confirmed visit reference and both people, or a clear refusal with no new confirmed booking. Preserve entered details when the request cannot proceed. If the response is lost or a commit outcome is uncertain, reconcile the saved outcome using the same request ID before attempting another booking.

A timeout proves neither success nor failure. The operation f includes coordination with stored state; it is not a pure calculation.

**Notification worker — independent after commit**

A separate worker reads committed outbox records, sends the customer update and records notification status. Retry a failed notification without creating another booking, and account for repeated processing or delivery.

Notification delivery and the coordinator’s reply can complete at different times. Notification status is separate from booking status and whether a visit takes place.

**Visit & feedback — compare the promise with reality**

The field team uses the saved appointment through the application and records arrival, completion or an exception against the visit. The saved-booking connector represents this operational handoff, not direct database access. Review the outcome independently of notification delivery.

**Review the rule — close the human feedback loop**

The business owner reviews recurring gaps. An analyst updates the relevant Confluence rationale and identifies affected Jira work, owners and validation criteria. An accepted document decision does not change the running application: a changed rule takes effect only after implementation, validation and release.

VIS-CHG-02 remains proposed in the scenario. This map imagines its possible future operation after that release; it claims no implementation or completed tests.

Fictional proposed design, not an observed execution. VIS-CHG-02 remains proposed. The database participates in the decision and records its result; a document decision becomes application behaviour only through delivery and release.

### Keep the safeguards explicit

-   **All-or-nothing is not the whole overlap rule.** A transaction alone does not stop two concurrent requests accepting the same slot. The design needs an appropriate locking, constraint or isolation strategy and checks that challenge it.
-   **A request ID needs behaviour behind it.** Store and recognise repeated attempts. Return the established outcome for the same request; reject reuse with different booking details. A timeout alone proves neither success nor failure.
-   **Booked and notified are different states.** Track notification progress separately. A sender retry must not create another booking, and repeated delivery must be considered.

Engineering references: PostgreSQL explains [transaction atomicity](https://www.postgresql.org/docs/current/tutorial-transactions.html) and gives an [exclusion-constraint example for overlapping reservations](https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-CONSTRAINT). AWS describes the [transactional outbox and duplicate processing](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html). These references support the safeguards; neither product is a selected stack for this fictional design.

**Use the same observation questions in another workplace**

![An architect and a silver-haired coordinator observe packing and dispatch in a fictional workshop.](https://treenodes.com/assets/articles/jira-confluence-observe-real-work-treenodes.webp?v=9c075039aa51)

What arrives, who decides, and what leaves each step? Try those questions in your own workplace. Conceptual artwork; this workshop is separate from the booking example.

## Try it: can a colleague follow the change?

Pick one requirement that changed recently. Give a colleague its Jira story and ask them to find the reason, decision owner, impacted work and validation evidence.

**How to try it.** Use a requirement you are allowed to review, or one of the fictional scenarios above. Copy the worksheet, fill in the records you can locate and mark missing evidence as pending. Ask your colleague to follow the links without an extra verbal explanation.

Decision-to-delivery worksheet

Capture the real operation, decisions, affected work and evidence in one small record.

[Download file](https://treenodes.com/downloads/practice/decision-to-delivery-worksheet.txt)

**Full prompt**

```
Business question and intended outcome:
Current operating baseline:
Proposed design and unresolved assumptions:
Accepted decision, reason and decision owner:
Affected Jira work, owners and dependencies:
Acceptance criteria:
Later change and proposed record updates:
Validation evidence, reviewer and tested version (or pending):
```

### What your result should show

-   Another person can explain what changed, why, who agreed it, what work is affected and what evidence exists.
-   The current operating baseline, proposed design and accepted change remain distinct. Acceptance does not imply release or a successful test.
-   Missing evidence becomes a specific next action with an owner; it is not presented as proof of completion.

### Change one condition

Reverse the exercise: start at the Confluence decision and trace forward to every affected story and its validation record. Mark unexecuted checks as pending.

**A useful requirement helps the next person make the right decision—and recognise when that decision needs to change.**

## Takeaways

-   Start with one real case, validate its map with the people doing the work, and distinguish current operations from proposed improvements.
-   Keep shared context in one place and give each delivery item a specific behaviour to implement.
-   When the requirement changes, review the decision, affected work and validation together.

READING PATH · 6 OF 6

## Improving business workflows

Understand the work people actually do before changing the software that supports it.

You’ve reached the end of this path. [Choose another reading path →](https://treenodes.com/articles/reading-paths/)

[View the complete reading path](https://treenodes.com/articles/reading-paths/#work-the-system-cannot-see)

1.  [01 Software should follow the business](https://treenodes.com/articles/software-should-follow-the-business/)
2.  [02 The person missing from the diagram](https://treenodes.com/articles/the-person-missing-from-the-diagram/)
3.  [03 What the spreadsheet knows that the system does not](https://treenodes.com/articles/what-the-spreadsheet-knows-that-the-system-does-not/)
4.  [04 The exception path is the real workflow](https://treenodes.com/articles/the-exception-path-is-the-real-workflow/)
5.  [05 Kaizen, applied to software](https://treenodes.com/articles/kaizen-and-software/)
6.  06 Jira and Confluence: From a Business Question to a Working Feature

**REFERENCES AND FURTHER READING  — 12 sources**

1.  [How to create a product requirements document](https://www.atlassian.com/agile/product-management/requirements)  — Dan Radigan, Atlassian  — Editorial reference for collaborative requirements and linked delivery work. Official documentation checked 15 September 2026.
2.  [Display Jira work items in a list](https://support.atlassian.com/confluence-cloud/docs/insert-the-jira-issues-macro/)  — Atlassian Support  — Confluence Cloud display controls. Official documentation checked 15 September 2026.
3.  [Link a Confluence page to a parent-level work item](https://support.atlassian.com/jira-software-cloud/docs/link-a-confluence-page-to-an-epic/)  — Atlassian Support  — Connected, company-managed Jira Cloud instructions. Official documentation checked 15 September 2026.
4.  [Work types and hierarchy](https://support.atlassian.com/jira-cloud-administration/docs/what-are-issue-types/)  — Atlassian Support  — Default hierarchy and plan limitations. Official documentation checked 15 September 2026.
5.  [Link work items](https://support.atlassian.com/jira-software-cloud/docs/link-issues/)  — Atlassian Support  — Relationship types and linked work. Official documentation checked 15 September 2026.
6.  [Configure work item linking](https://support.atlassian.com/jira-cloud-administration/docs/configure-issue-linking/)  — Atlassian Support  — Linking configuration and permissions. Official documentation checked 15 September 2026.
7.  [Team-managed space permissions](https://support.atlassian.com/jira-software-cloud/docs/next-gen-permissions/)  — Atlassian Support  — Permission names and cross-space linking. Official documentation checked 15 September 2026.
8.  [Configure the work type hierarchy](https://support.atlassian.com/jira-cloud-administration/docs/configure-the-issue-type-hierarchy/)  — Atlassian Support  — Optional levels above epic, plan and company-managed scope. Checked 16 September 2026.
9.  [Use automation steps in a flow](https://support.atlassian.com/cloud-automation/docs/what-are-automation-rules/)  — Atlassian Support  — Triggers, conditions and actions. Checked 16 September 2026.
10.  [Transactions](https://www.postgresql.org/docs/current/tutorial-transactions.html)  — PostgreSQL documentation  — Engineering reference for all-or-nothing writes. Checked 16 September 2026; no database engine is selected for the fictional application.
11.  [Constraints on ranges](https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-CONSTRAINT)  — PostgreSQL documentation  — An example safeguard against overlapping reservations. Checked 16 September 2026.
12.  [Transactional outbox pattern](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html)  — AWS Prescriptive Guidance  — Engineering reference for recording notification work with a database change. Checked 16 September 2026; AWS is not a proposed deployment requirement.