Guided build 06: a confirmed service-request conversation

Lab 06 | Orientation | Handoff card

Build basis: RULE-06, service knowledge and service test cases.

1. Check the prepared starter

Your card must link:

• An editable Copilot Studio starter agent with a rehearsed authenticated training channel.
• A prepared Create Training Service Request agent flow.
• An allowed test user and a denied test user.
• A Dataverse request store, active request-key uniqueness and an operator read-back app.

The flow validates category/description, uses the intended caller's effective permissions, handles same-key replay and returns outcome/reference/error. You build the topic and its confirmation experience. You do not invent authentication, authorization or a transactional persistence implementation.

The facilitator supplies the actual flow input/output labels and the rehearsal result for both users. If the flow only works with a maker's shared credentials, the starter is not ready.

2. Ask HVE for a plain-language walkthrough

In Cowork:

[BEGIN STANDALONE CONTEXT]
STANDALONE-1.0 / Exercise 06 / 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 06: Copilot Studio agent, Agent flow
## Feature and schema decision workflow

| Step | Agent-service decision | HVE output | Used before |
|---|---|---|---|
| DS06-1 | What user/service jobs should the agent support? | Needs, authority boundaries and feature questions | Choosing knowledge/actions |
| DS06-2 | Which conversational/action features are needed now? | Prioritized explain/collect/confirm/create/status choices | Designing topics or tools |
| DS06-3 | What is transient conversation versus persistent business data? | Compared request/action/identity/history models | Creating storage or action contracts |
| DS06-4 | How do status lookup and changed details affect the design? | Feature/access/identity/history impact | Adding more actions |
| DS06-5 | Can the design support safe useful journeys? | Feature/schema decision pack | Prototype and acceptance planning |

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-06 / Service:** Only authenticated test users with effective request-store permission may create a service request. Categories are `Repair` and `Delivery`; description is required and at most 500 characters. A human confirms the displayed payload before action. A caller-scoped request key prevents duplicate creation. A denied caller must not write through a privileged shared connection.

SOURCE: client/hve-development/06-agent.md
# Case 06: what should the service agent know and do?

**HVE-DECISIONS-1.0. Fictional client interview/design feedback. RULE-06, approved knowledge and service-cases.csv remain authoritative.**

## Client interview evidence

- **C06-F1 / Mia:** "The agent should explain Repair and Delivery. It may help an employee submit a request, but it cannot promise a booking or compensation."
- **C06-F2 / Employee:** "Before anything is submitted, show the category and my description so I can correct or cancel."
- **C06-F3 / Service team:** "A request needs an accountable requester, reference, category, description and review status."
- **C06-F4 / Operator:** "If a user retries, they should not create a second request. If details changed, we must distinguish a new request from a retry."
- **C06-F5 / Mia:** "We have not asked to retain entire conversations. Do not store passwords, payroll or payment details just because they appear in chat."
- **C06-F6:** Allowed categories are Repair/Delivery, description is required and at most 500 characters, and the intended caller must have permission.

## Technology-specific decision context

Copilot Studio can answer from approved knowledge, collect information and call a bounded business action. Decide which of those capabilities the first service needs, what must remain human-owned and what information is transient conversation state versus persistent business data.

Do not assume that every conversational variable needs a database table or that adding a tool authorizes every user.

## Proposal to inspect

- **C06-P1:** Give the agent booking, compensation and payroll tools to make it look useful.
- **C06-P2:** Persist every chat message and use it as the only request record.
- **C06-P3:** A retry is always a new request; a changed description always overwrites the existing request.

## Change for discussion

- **C06-C1:** Mia asks whether users should see request status later. Decide the feature, identity/data needs and access boundaries before adding it.
- **C06-C2:** The user changes category after seeing the summary. Determine what confirmation/identity/history information must be retained and what can remain transient.

## Supplied fictional design-review feedback

| ID | Walkthrough finding |
|---|---|
| C06-T1 | The feature list confuses request submission with repair booking. |
| C06-T2 | The model has no stable way to identify the same request across a retry. |
| C06-T3 | Conversation text is stored but the service team cannot identify the accountable requester or request state. |
| C06-T4 | Status lookup would reveal another employee's requests. |
| C06-T5 | Unnecessary full-chat retention is included without a stated business purpose. |

No live agent conversation, flow execution or stored-row test is supplied.


SOURCE: client/offerings/service-cases.csv
case_id,test_user,request_key,category,description
SR-01,Allowed A,REQ-A-001,Repair,Training pump needs inspection
SR-02,Allowed A,REQ-A-001,Repair,Training pump needs inspection
SR-03,Denied B,REQ-B-001,Delivery,Training parcel has not arrived
SR-04,Allowed A,REQ-A-002,Payroll,Please change my salary


SOURCE: client/offerings/service-knowledge.md
# Approved training service knowledge

**ZAVA-PP-2.0. Synthetic authority for labs 01 and 06.**

## KB-01: service boundaries

Zava accepts Repair and Delivery requests. The service team reviews priority and assignment. A created request is not a repair booking, delivery promise or compensation approval.

## KB-02: information to provide

Supply a category and a description of up to 500 characters. Do not include passwords, payment details or sensitive employee data. The service agent displays the request for confirmation before creation. If creation fails, it must say so and offer a retry using the same request key or a manual handoff.

## KB-03: unsupported request

Payroll advice, employment decisions and supplier payment changes are outside this service. Direct the user to the relevant human service owner without inventing contact details.

OPTIONAL RECIPE (example only; reconcile with actual reviewed design and facilitator readiness)
# Guided build 06: a confirmed service-request conversation

[Lab 06](../06-service-agent.md) | [Orientation](README.md) | [Handoff card](training-handoff.md)

**Build basis:** [RULE-06](../client/offerings/README.md), [service knowledge](../client/offerings/service-knowledge.md) and [service test cases](../client/offerings/service-cases.csv).

## 1. Check the prepared starter

Your card must link:

- An editable Copilot Studio starter agent with a rehearsed authenticated training channel.
- A prepared **Create Training Service Request** agent flow.
- An allowed test user and a denied test user.
- A Dataverse request store, active request-key uniqueness and an operator read-back app.

The flow validates category/description, uses the intended caller's effective permissions, handles same-key replay and returns outcome/reference/error. You build the topic and its confirmation experience. You do not invent authentication, authorization or a transactional persistence implementation.

The facilitator supplies the actual flow input/output labels and the rehearsal result for both users. If the flow only works with a maker's shared credentials, the starter is not ready.

## 2. Ask HVE for a plain-language walkthrough

In Cowork:



**Expected:** confirmation does not grant the denied user permission.

## 3. Prepare the knowledge explanation

1. Open [Copilot Studio](https://copilotstudio.microsoft.com/), select the training environment and open the named starter agent.
2. Open **Knowledge** and add the supplied service-knowledge file or its supported prepared equivalent.
3. Wait for Ready status. Record which sources are enabled. Keep unrelated sources and web search disabled as specified on the card.
4. In the test panel ask `What information do I need for a Repair request?`.
5. Compare the actual answer with KB-01/02. It should not promise a booking or compensation.

If the file is not ready, repair indexing with the facilitator rather than treating an ungrounded answer as a source-backed result.

## 4. Create the deterministic topic

1. Open **Topics > Add a topic > From blank**. Name it `Create service request`.
2. Use the rehearsed topic trigger, for example `I need to submit a service request`. Keep this path deterministic for the exercise.
3. Add a **Question** node: `Is this a Repair or Delivery request?` Use multiple-choice options Repair and Delivery. Store the answer in the topic variable `Category`.
4. Add a Question node: `Describe the request in up to 500 characters. Do not include passwords or payment details.` Store as `Description`.
5. Add the starter's supplied validation condition for nonempty description and maximum length. The facilitator provides the tested expression for the actual variable type. On invalid input, explain the issue and ask again.
6. Add a **Message** node displaying both selected Category and Description through the variable picker.
7. Add a Yes/No confirmation question: `Create this service request with the details above?` Store the answer as `Confirmed`.
8. Add a **Condition**: Confirmed is Yes. The No branch sends `Nothing was submitted` and ends the topic.

**Expected:** no flow call exists before confirmation. If a user changes a value, route back to the display and confirmation, not directly to the action.

## 5. Preserve a request key

The starter provides a topic variable `RequestKey` initialized once per intended request. Inspect it with the facilitator. It must remain unchanged on a retry.

For the controlled fixture run, the facilitator sets REQ-A-001 for SR-01/02 through the test harness. Ordinary requests use the starter's collision-resistant key generation. Do not ask users or a language model to supply an authenticated caller ID.

You are learning replay behavior, not expected to design an identity or key service.

## 6. Call the prepared flow and handle its outputs

Inside the Yes branch:

1. Add **Call an action / Add a tool**, selecting the card's Create Training Service Request flow.
2. Map RequestKey, Category and Description using the topic-variable picker. Do not type their names as literal strings.
3. Store the outputs in topic variables Outcome, RequestReference and ErrorText, using the actual supplied mapping.
4. Add a Condition on Outcome:
   - Created or Existing: display `Your request reference is [RequestReference]. The service team will review it.`
   - Conflict: explain that the same request key has different details and hand off for review.
   - Denied/Failed: display the safe error and the documented manual handoff. Do not manufacture a reference.
5. Save the topic. Use the starter's rehearsed private test channel to run as the actual end user.

Do not externally publish the agent. The facilitator performs any deployment needed to refresh the private training channel.

## 7. Walk the actual cases

| Try | Observe |
|---|---|
| Allowed user, Repair, valid description, Yes | One store row and a verified reference |
| Same key and exact payload again | Same reference, not a second row |
| Same key with changed details | Conflict; original unchanged |
| Denied user, Delivery, Yes | No new row |
| Valid input followed by No | No flow action |
| Payroll request | Out of scope; no service creation |

For every write case, the facilitator's read-back app shows actual row identity, owner and content. A transcript saying "created" alone is insufficient.

The facilitator triggers a safe downstream failure and supplies its result. Learners inspect how their topic displays it. Do not disable a shared connection yourself.

## 8. Return to HVE and transfer

Attach the topic path, transcripts and actual store observations. Ask the main lab's review prompt to check confirmation, caller permissions and replay separately.

Give a partner the recipe. They change one user-facing explanation, rerun cancellation and successful creation, and explain why that wording change cannot grant backend authority.

Package the topic, approved knowledge, prepared flow contract, channel requirements, operator runbook and case-level tests. The offering requires both maker work and reviewed identity preparation; do not present it as "just add a tool."

**Reference:** [Agent-flow trigger, response and connection requirements](https://learn.microsoft.com/microsoft-copilot-studio/advanced-flow-create).
[END STANDALONE CONTEXT]

Use guided build 06 and the prepared action contract.
Explain the difference between the conversation collecting values,
a person confirming them and the backend allowing a write.
Walk through SR-01 and SR-03 without inventing run results.
Keep the topic build separate from the facilitator's prepared
identity and request-store implementation.

Expected: confirmation does not grant the denied user permission.

3. Prepare the knowledge explanation

1. Open Copilot Studio, select the training environment and open the named starter agent.
2. Open Knowledge and add the supplied service-knowledge file or its supported prepared equivalent.
3. Wait for Ready status. Record which sources are enabled. Keep unrelated sources and web search disabled as specified on the card.
4. In the test panel ask What information do I need for a Repair request?.
5. Compare the actual answer with KB-01/02. It should not promise a booking or compensation.

If the file is not ready, repair indexing with the facilitator rather than treating an ungrounded answer as a source-backed result.

4. Create the deterministic topic

1. Open Topics > Add a topic > From blank. Name it Create service request.
2. Use the rehearsed topic trigger, for example I need to submit a service request. Keep this path deterministic for the exercise.
3. Add a Question node: Is this a Repair or Delivery request? Use multiple-choice options Repair and Delivery. Store the answer in the topic variable Category.
4. Add a Question node: Describe the request in up to 500 characters. Do not include passwords or payment details. Store as Description.
5. Add the starter's supplied validation condition for nonempty description and maximum length. The facilitator provides the tested expression for the actual variable type. On invalid input, explain the issue and ask again.
6. Add a Message node displaying both selected Category and Description through the variable picker.
7. Add a Yes/No confirmation question: Create this service request with the details above? Store the answer as Confirmed.
8. Add a Condition: Confirmed is Yes. The No branch sends Nothing was submitted and ends the topic.

Expected: no flow call exists before confirmation. If a user changes a value, route back to the display and confirmation, not directly to the action.

5. Preserve a request key

The starter provides a topic variable RequestKey initialized once per intended request. Inspect it with the facilitator. It must remain unchanged on a retry.

For the controlled fixture run, the facilitator sets REQ-A-001 for SR-01/02 through the test harness. Ordinary requests use the starter's collision-resistant key generation. Do not ask users or a language model to supply an authenticated caller ID.

You are learning replay behavior, not expected to design an identity or key service.

6. Call the prepared flow and handle its outputs

Inside the Yes branch:

1. Add Call an action / Add a tool, selecting the card's Create Training Service Request flow.
2. Map RequestKey, Category and Description using the topic-variable picker. Do not type their names as literal strings.
3. Store the outputs in topic variables Outcome, RequestReference and ErrorText, using the actual supplied mapping.
4. Add a Condition on Outcome:
   • Created or Existing: display Your request reference is [RequestReference]. The service team will review it.
   • Conflict: explain that the same request key has different details and hand off for review.
   • Denied/Failed: display the safe error and the documented manual handoff. Do not manufacture a reference.
5. Save the topic. Use the starter's rehearsed private test channel to run as the actual end user.

Do not externally publish the agent. The facilitator performs any deployment needed to refresh the private training channel.

7. Walk the actual cases

For every write case, the facilitator's read-back app shows actual row identity, owner and content. A transcript saying "created" alone is insufficient.

The facilitator triggers a safe downstream failure and supplies its result. Learners inspect how their topic displays it. Do not disable a shared connection yourself.

8. Return to HVE and transfer

Attach the topic path, transcripts and actual store observations. Ask the main lab's review prompt to check confirmation, caller permissions and replay separately.

Give a partner the recipe. They change one user-facing explanation, rerun cancellation and successful creation, and explain why that wording change cannot grant backend authority.

Package the topic, approved knowledge, prepared flow contract, channel requirements, operator runbook and case-level tests. The offering requires both maker work and reviewed identity preparation; do not present it as "just add a tool."

Reference: Agent-flow trigger, response and connection requirements.