Frontier Consultancy
POWER PLATFORM LANE · HVE-first course. Supplied fictional feedback is not live execution.
Download Markdown sourceAfter a prompt: find output and next actionCopy prompts below. Review every proposed action before running it.

Guided build 07: automate a local ledger and reconcile a saved job

Lab 07 | Orientation | Handoff card

Build basis: RULE-07 and bridge jobs, plus the supplied training ledger. This is a local UI fixture, not an ERP.

1. Get a working machine, not an infrastructure assignment

The facilitator supplies a registered training machine, permitted desktop-flow connection, browser extension/profile, stable local ledger URL and a starter desktop flow.

The starter contains:

You will record the UI entry steps, call the desktop flow from a cloud flow and observe reconciliation. You are not expected to register a machine or design transaction recovery from scratch.

2. Ask HVE to explain the uncertainty

In Cowork:

[BEGIN STANDALONE CONTEXT]
STANDALONE-1.0 / Exercise 07 / optional implementation reference
This request includes its static teaching context below. Do not assume access to course pages, local files, attachments or earlier chat. Source filenames and DS/RULE IDs identify the included evidence, not documents you must fetch.

Use the installed HVE Squad Cowork plugin and the actual authorized selected project. Confirm project identity before creating/adopting a project or starting managed work. New managed work uses the normal squad_run entry point; the server owns routing. Follow an existing working run rather than duplicating it. Do not invent project/run/question/artifact IDs, links or approvals.

If the task depends on reviewed needs, selected features, a preferred model, a handoff, a real run or runtime observations: retrieve the actual verified originals in the selected project, showing their real provenance and the human choices. Earlier exercise content labels can help locate substantive originals through project START-HERE.md and library/deliverables.md; labels echoed in journals are not deliverables. If inputs are absent, ambiguous or unaccepted, list precisely what is missing and ask me to supply the actual original/reference or make the needed workshop decision. Pause dependent work. Do not infer selected scope from candidate proposals or invent earlier acceptance. A missing learner decision cannot be filled by static scenario data.

The current task below defines the decision step. Use interview facts and applicable rules as evidence. Candidate proposals, future changes and supplied design-review findings are fiction to inspect, not approved first-release requirements or executed tests. Unverified licensing/capability/access facts remain open. Core work is feature/schema decisions, not code or designer repairs. Optional maker work requires a separately reviewed design, prepared environment/handoff and actual observations; an example recipe is not proof those exist.

Keep the requested output label in substantive original content. Preserve server-owned canonical paths. Return verified original links and distinguish run outcome, mirror state and document acceptance. Content labels are not filenames or real IDs. Workshop choices do not release operator gates. No production writes, real recipients, ERP actions, external publication or claimed deployment are authorized.

EXERCISE 07: Power Automate desktop flow, Power Automate cloud flow
## Feature and schema decision workflow

| Step | Legacy-service decision | HVE output | Used before |
|---|---|---|---|
| DS07-1 | What must operators know/do during uncertain completion? | Needs and feature questions | Selecting automation-only versus managed service |
| DS07-2 | Which queue/reconciliation/history features are essential? | Prioritized operating capability choices | Designing desktop/cloud actions |
| DS07-3 | What job, attempt, observation and resolution data is needed? | Schema alternatives and lifecycle meanings | Building the queue/review experience |
| DS07-4 | How do more reviewers/targets change the model? | Scope/association/history impact | Expanding beyond one worker/target |
| DS07-5 | Can the data support a safe operating decision? | Feature/schema decision pack | Prototype/build and service ownership |

SCENARIO AUTHORITY
Zava and Nora are fictional. All interviews, policies and records below are synthetic training evidence, not real client data or executed tests. Amounts are EUR and timestamps UTC. CSVs are examples, not prescribed tables.

## People and decisions

| Role | Fictional owner | Authority in the scenario |
|---|---|---|
| CoE sponsor | Priya, operations director | Scope, value and operating-model decisions |
| Order operations | Lena | Order validation and human handoff |
| Process owner | Omar | Order-to-cash experiment |
| Field service | Eva | Inspections and remediation acceptance |
| Procurement | Arun | Supplier review |
| Service operations | Mia | Service-request policy |
| Dispatch | Noah | Scheduling rules |
| Finance | Lina | Leakage investigation, never automatic recovery |
| Platform owner | Jules | Sandbox configuration and technical release |

Learners playing these roles sign **workshop role-play**. Fictional authority does not authorize real tenant actions.

APPLICABLE POLICIES (complete text)
- **RULE-01 / Boundaries:** Training sandbox only. Human acceptance, technical release and business approval are separate. No real email recipients, ERP writes, payments or external publication.
- **RULE-07 / Legacy:** Preserve job ID as the ledger's unique reference. Search before create; after uncertain completion, reconcile before retry. One learner/worker uses a ledger instance at a time. No financial posting.

SOURCE: client/hve-development/07-legacy.md
# Case 07: what makes a legacy handoff safe to operate?

**HVE-DECISIONS-1.0. Fictional interview/design feedback. RULE-07 and bridge-jobs.csv define the first pilot.**

## Client interview evidence

- **C07-F1 / Operations:** "The target has only a UI in this pilot. We need a reliable handoff, not a production integration claim."
- **C07-F2 / Operator:** "Sometimes the caller loses the response after Save. We need to distinguish unknown completion from definitely not saved."
- **C07-F3 / Operator:** "Before retrying, I need the source reference, intended values and what we observed in the target."
- **C07-F4 / Service owner:** "One job can have several attempts. I need to explain what happened, not just overwrite the last error."
- **C07-F5 / Reviewer:** "If the target contains the same reference with different values, someone must decide what is correct."
- **C07-F6:** One worker and one training target apply initially. Stable Job ID is available; no financial posting is authorized.

## Technology-specific decision context

Power Automate cloud/desktop capabilities can bridge a UI-only process. Decide which supporting features are required: durable work queue, duplicate recognition, operator reconciliation, attempt history, exception review and recovery ownership.

Choose the data needed to support those decisions. Do not begin by recording UI actions or configuring retries.

## Proposal to inspect

- **C07-P1:** Keep only Job ID and a Done flag.
- **C07-P2:** Overwrite the intended payload and all earlier attempts whenever a retry starts.
- **C07-P3:** A caller failure always means the target has no record.

## Change for discussion

- **C07-C1:** More than one operator may review held jobs. Decide assignment/accountability and any claim/history data needed.
- **C07-C2:** Another target may eventually use a different reference format. Identify what belongs to the reusable job model versus target-specific mapping.

## Supplied fictional design-review feedback

| ID | Walkthrough finding |
|---|---|
| C07-T1 | JOB-02 can be marked only Done or Not done, although target completion is uncertain. |
| C07-T2 | A second attempt removes evidence of the first payload/result. |
| C07-T3 | A reviewer cannot compare intended quantity 2 with a different observed target value. |
| C07-T4 | Two people can make different resolution decisions with no accountable owner/history. |

These are feature/schema review findings, not a desktop trace to debug.


SOURCE: client/offerings/bridge-jobs.csv
job_id,customer_ref,quantity
JOB-01,C-100,3
JOB-02,C-100,2
JOB-03,C-100,1

OPTIONAL RECIPE (example only; reconcile with actual reviewed design and facilitator readiness)
# Guided build 07: automate a local ledger and reconcile a saved job

[Lab 07](../07-legacy-bridge.md) | [Orientation](README.md) | [Handoff card](training-handoff.md)

**Build basis:** [RULE-07 and bridge jobs](../client/offerings/README.md), plus the supplied [training ledger](../client/offerings/legacy-ledger.html). This is a local UI fixture, not an ERP.

## 1. Get a working machine, not an infrastructure assignment

The facilitator supplies a registered training machine, permitted desktop-flow connection, browser extension/profile, stable local ledger URL and a starter desktop flow.

The starter contains:

- Inputs JobId, CustomerRef, Quantity, FixtureUrl and FailAfterSave.
- Outputs Outcome, TargetReference and SafeError.
- Prepared existing-record comparison, error handling and a fail-after-save checkpoint.
- A Bridge Job queue app with Pending, Running, Verified, NeedsReconciliation and Failed states.

You will record the UI entry steps, call the desktop flow from a cloud flow and observe reconciliation. You are not expected to register a machine or design transaction recovery from scratch.

## 2. Ask HVE to explain the uncertainty

In Cowork:



**Expected:** "unknown until checked," not "the target rolled back."

## 3. Try the target manually

1. On the supplied machine open the exact ledger URL in the named browser profile.
2. In Job ID enter `JOB-01`, Customer reference `C-100`, Quantity `3`. Choose **Save record**.
3. In Find job ID enter JOB-01 and choose Find.
4. Read the result and table row. Remove that exact test row using the supplied exact-ID control so the automation starts clean.

**Expected:** save, find and exact removal work in the same origin/profile. If not, ask the facilitator before recording automation.

## 4. Record the new-record entry branch

1. Open Power Automate for desktop and the supplied `Zava Ledger Bridge Starter`.
2. Inspect its input variables with the facilitator. Do not rename inputs already mapped by the starter.
3. Locate the clearly labeled **Create when absent** subflow/section. The prepared search branch calls this only when JobId does not exist.
4. Use the web recorder or UI-element picker to capture Job ID, Customer reference, Quantity and Save record on the local ledger.
5. Use **Populate text field on web page** for Job ID; its value is `%JobId%`, selected from the variable picker.
6. Repeat for Customer reference with `%CustomerRef%` and Quantity with `%Quantity%`.
7. Use **Press button on web page** for Save record.
8. Keep the starter's post-save search/read-back and FailAfterSave checkpoint. Do not delete them to shorten the recording.

The target controls have stable names. Use UI-element selectors, not screen coordinates. If the picker cannot find a control, ask the facilitator to correct the browser extension/profile setup.

**Expected:** the new-record branch enters the variables, not hardcoded JOB-01 values.

## 5. Run a local desktop test

1. Run the starter with JOB-01, C-100, 3, the provided URL and FailAfterSave false.
2. Observe the saved target and the flow's actual outputs.
3. Run again with identical values.

**Expected:** the second run finds and compares the existing row. There remains one target row; Outcome can be Verified without a second create.

If the existing row has a different quantity, the prepared comparison must return NeedsReconciliation rather than overwrite it.

## 6. Connect the cloud flow

In Power Automate's browser tool, inside the prepared solution:

1. Create an Instant flow named `Run training ledger job`.
2. Trigger **Manually trigger a flow**. Add Text JobId, Text CustomerRef, Number Quantity and Yes/No FailAfterSave inputs.
3. Add **Run a flow built with Power Automate for desktop**.
4. Choose the approved attended connection and the edited starter flow.
5. Map the four inputs through dynamic content. FixtureUrl is the exact provided local URL.
6. Open this action's settings and use the rehearsed no-automatic-retry configuration.
7. Use the prepared queue-update/failure-handling section from the facilitator's flow shell. It maps Verified versus NeedsReconciliation explicitly; the card names the actual queue row/action outputs.
8. Save. Do not switch to an unattended connection or another browser profile.

**Expected:** cloud dispatch runs your recorded desktop steps on the supplied machine. Merely selecting the flow in the designer does not prove execution.

## 7. Fail after save, then reconcile

1. Test JOB-02, C-100, 2, FailAfterSave true.
2. Check the target directly. JOB-02 should exist even though the caller reports failure/uncertainty.
3. Check the queue's actual NeedsReconciliation state.
4. Run again with the same job values and FailAfterSave false.
5. Verify the prepared search branch finds JOB-02 and compares its values.

**Expected:** one target row and Verified after reconciliation. Do not delete the target record to manufacture a clean retry.

The facilitator demonstrates an unavailable-target case for JOB-03 and its operator-visible failure. Preserve the actual result.

## 8. Return to HVE and hand over

Attach cloud run outputs, desktop observations, target rows and queue states. Use the main lab's review prompt.

Ask a receiving operator to reconcile a held job using only this recipe and the supplied runbook. Record help needed.

Your offering package includes recorded selectors, the prepared queue/recovery components, machine/profile requirements and exact-record cleanup. Local browser persistence is not proof of production durability or multi-worker safety.

**Explain back:** why is a caller's failed action not enough to decide whether Create can be repeated?
[END STANDALONE CONTEXT]

Use guided build 07. Explain what can happen when Save succeeds on
the target but the caller times out. Walk through JOB-02 with no
invented outcomes. Identify the prepared reconciliation branch and
the UI steps I will record. Do not replace it with blind retry.

Expected: "unknown until checked," not "the target rolled back."

3. Try the target manually

  1. On the supplied machine open the exact ledger URL in the named browser profile.
  2. In Job ID enter JOB-01, Customer reference C-100, Quantity 3. Choose Save record.
  3. In Find job ID enter JOB-01 and choose Find.
  4. Read the result and table row. Remove that exact test row using the supplied exact-ID control so the automation starts clean.

Expected: save, find and exact removal work in the same origin/profile. If not, ask the facilitator before recording automation.

4. Record the new-record entry branch

  1. Open Power Automate for desktop and the supplied Zava Ledger Bridge Starter.
  2. Inspect its input variables with the facilitator. Do not rename inputs already mapped by the starter.
  3. Locate the clearly labeled Create when absent subflow/section. The prepared search branch calls this only when JobId does not exist.
  4. Use the web recorder or UI-element picker to capture Job ID, Customer reference, Quantity and Save record on the local ledger.
  5. Use Populate text field on web page for Job ID; its value is %JobId%, selected from the variable picker.
  6. Repeat for Customer reference with %CustomerRef% and Quantity with %Quantity%.
  7. Use Press button on web page for Save record.
  8. Keep the starter's post-save search/read-back and FailAfterSave checkpoint. Do not delete them to shorten the recording.

The target controls have stable names. Use UI-element selectors, not screen coordinates. If the picker cannot find a control, ask the facilitator to correct the browser extension/profile setup.

Expected: the new-record branch enters the variables, not hardcoded JOB-01 values.

5. Run a local desktop test

  1. Run the starter with JOB-01, C-100, 3, the provided URL and FailAfterSave false.
  2. Observe the saved target and the flow's actual outputs.
  3. Run again with identical values.

Expected: the second run finds and compares the existing row. There remains one target row; Outcome can be Verified without a second create.

If the existing row has a different quantity, the prepared comparison must return NeedsReconciliation rather than overwrite it.

6. Connect the cloud flow

In Power Automate's browser tool, inside the prepared solution:

  1. Create an Instant flow named Run training ledger job.
  2. Trigger Manually trigger a flow. Add Text JobId, Text CustomerRef, Number Quantity and Yes/No FailAfterSave inputs.
  3. Add Run a flow built with Power Automate for desktop.
  4. Choose the approved attended connection and the edited starter flow.
  5. Map the four inputs through dynamic content. FixtureUrl is the exact provided local URL.
  6. Open this action's settings and use the rehearsed no-automatic-retry configuration.
  7. Use the prepared queue-update/failure-handling section from the facilitator's flow shell. It maps Verified versus NeedsReconciliation explicitly; the card names the actual queue row/action outputs.
  8. Save. Do not switch to an unattended connection or another browser profile.

Expected: cloud dispatch runs your recorded desktop steps on the supplied machine. Merely selecting the flow in the designer does not prove execution.

7. Fail after save, then reconcile

  1. Test JOB-02, C-100, 2, FailAfterSave true.
  2. Check the target directly. JOB-02 should exist even though the caller reports failure/uncertainty.
  3. Check the queue's actual NeedsReconciliation state.
  4. Run again with the same job values and FailAfterSave false.
  5. Verify the prepared search branch finds JOB-02 and compares its values.

Expected: one target row and Verified after reconciliation. Do not delete the target record to manufacture a clean retry.

The facilitator demonstrates an unavailable-target case for JOB-03 and its operator-visible failure. Preserve the actual result.

8. Return to HVE and hand over

Attach cloud run outputs, desktop observations, target rows and queue states. Use the main lab's review prompt.

Ask a receiving operator to reconcile a held job using only this recipe and the supplied runbook. Record help needed.

Your offering package includes recorded selectors, the prepared queue/recovery components, machine/profile requirements and exact-record cleanup. Local browser persistence is not proof of production durability or multi-worker safety.

Explain back: why is a caller's failed action not enough to decide whether Create can be repeated?