# Guided build 10: deploy and configure the service for Nora [Lab 10](../10-repeatable-accelerator.md) | [Orientation](README.md) | [Handoff card](training-handoff.md) **Build basis:** the reviewed lab 05 service, [RULE-10](../client/offerings/README.md) and [Nora's change brief](../client/offerings/second-client.md). ## 1. Get actual deployment artifacts The facilitator must supply: - A passing lab 05 receipt and source solution/site version. - Its actual reviewed solution package and the required site metadata. - A source development environment and a separate private Nora target. - A completed source-to-target dependency/configuration worksheet. - Nora identities, Contact mappings and procurement team. - A rehearsal of the chosen site-data-model deployment route. The beginner route uses the **one rehearsed route named on the card**, not a choice between several ALM architectures. If the package is not available, this is not a live deployment exercise. The facilitator performs privilege-sensitive site provisioning, identity configuration and connection-secret entry. The learner follows the visible import/configuration procedure and tests the result. ## 2. Ask HVE to explain the package In Cowork: ```text [BEGIN STANDALONE CONTEXT] STANDALONE-1.0 / Exercise 10 / 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 10: Power Pages, Model-driven app, Power Platform solutions ## Feature and schema decision workflow | Step | Reuse decision | HVE output | Used before | |---|---|---|---| | DS10-1 | What accepted needs/features/model can actually be reused? | Evidence-backed baseline and open assumptions | Copying prior decisions | | DS10-2 | Which capabilities should be standard or variable? | Feature/variation boundary | Choosing one configurable product versus variants | | DS10-3 | What schema options support the differences? | Compared fixed/optional/reference/configuration models | Adding client-specific data | | DS10-4 | How do more regions or reviewers change it? | Feature/schema/history/ownership impact | Generalizing beyond the evidence | | DS10-5 | Can a receiver explain the new client's decisions? | Client-specific feature/schema decision pack | Prototype/build and reusable offering | 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-10 / Reuse:** Package structure and tests are reusable. Customer rules, identities and connection values are not universal. No secrets or training records in a deployment package. Receiving operators perform the new-client change without author coaching. - **RULE-05 / Suppliers:** A supplier contact sees only its own application. Required: legal name, country and tax reference. Procurement accepts or requests changes; submission never means approval. No bank details in this lab. SOURCE: client/hve-development/10-reuse.md # Case 10: what should be standard versus client-specific? **HVE-DECISIONS-1.0. Fictional interview/design feedback. Use RULE-05, RULE-10 and Nora's change brief.** ## Client interview evidence - **C10-F1 / Partner lead:** "Reuse the supplier-service learning, not a copy of Zava's customer data or project identity." - **C10-F2 / Nora:** "We need North/South service region before an application enters review." - **C10-F3 / Nora reviewer:** "Our team, notification destination and supplier identities are different. Missing settings must not fall back to another client." - **C10-F4 / Receiving consultant:** "I need to know why a feature/field was chosen and which assumptions must be checked again." - **C10-F5:** Use actual lab-05 decision artifacts if available; otherwise use its business boundary as a proposed baseline without invented history. ## Technology-specific decision context Power Platform solutions can package components, but reuse starts with the intended features, logical model, business rules and variation boundaries. Decide whether a request needs configuration, an additive schema change, a new feature or a separate product variant. Do not assume an optional Region field, existing feature flag, actual package or target deployment. Those are implementation facts to verify later. ## Proposal to inspect - **C10-P1:** Every new client gets a separate fork with no explanation of what changed. - **C10-P2:** Put all possible client variations into the first common schema, whether anyone needs them. - **C10-P3:** Rename Zava's entire project and contacts Nora, and treat earlier decisions as approved by the new client. ## Change for discussion - **C10-C1:** Nora may add more regions later. Compare a fixed Choice with a managed Region reference entity against actual ownership/change needs. - **C10-C2:** Another client wants two reviewers for high-risk applications. Identify feature/rule/schema impact without imposing that feature on every client. ## Supplied fictional design-review feedback | ID | Walkthrough finding | |---|---| | C10-T1 | The receiving person can see field names but not which client need each supports. | | C10-T2 | Nora's required-region feature has no schema/business-rule consequence. | | C10-T3 | Target team/destination/identity are assumed inherited from Zava. | | C10-T4 | No distinction exists between a reusable capability and a client-specific decision. | These are design-transfer findings, not solution import logs or evidence of deployed reuse. SOURCE: client/offerings/second-client.md # Nora: second-client adaptation **Synthetic change brief NORA-01..03. The HVE core uses the supplier-service boundary and relevant actual HVE artifacts where available. A deployed lab 05 application is needed only for the optional implementation extension.** - **NORA-01:** Nora Services requires an additional `Service region` choice: North or South. It is required before a submission is accepted into review, including API/form bypass attempts, not just visually marked on the page. An invalid attempt can be retained as evidence but cannot create a review application. - **NORA-02:** Supplier contacts see only their own applications, unchanged from RULE-05. Nora's test contacts are new identities; do not copy Zava contact rows. - **NORA-03:** Procurement uses a different sandbox review team and a different training notification recipient. Both are configuration. Missing configuration must stop processing with an explicit operator-visible failure, not default to Zava. No new customer data, site publication, bank details or ERP integration is authorized. In the core, the receiving consultant must find the accepted basis and obtain a credible adaptation handoff without private author coaching. Actual deployment/configuration tests are separate optional evidence. OPTIONAL RECIPE (example only; reconcile with actual reviewed design and facilitator readiness) # Guided build 10: deploy and configure the service for Nora [Lab 10](../10-repeatable-accelerator.md) | [Orientation](README.md) | [Handoff card](training-handoff.md) **Build basis:** the reviewed lab 05 service, [RULE-10](../client/offerings/README.md) and [Nora's change brief](../client/offerings/second-client.md). ## 1. Get actual deployment artifacts The facilitator must supply: - A passing lab 05 receipt and source solution/site version. - Its actual reviewed solution package and the required site metadata. - A source development environment and a separate private Nora target. - A completed source-to-target dependency/configuration worksheet. - Nora identities, Contact mappings and procurement team. - A rehearsal of the chosen site-data-model deployment route. The beginner route uses the **one rehearsed route named on the card**, not a choice between several ALM architectures. If the package is not available, this is not a live deployment exercise. The facilitator performs privilege-sensitive site provisioning, identity configuration and connection-secret entry. The learner follows the visible import/configuration procedure and tests the result. ## 2. Ask HVE to explain the package In Cowork: **Expected:** a concrete mapping to the supplied assets. "Use the supported route" without naming the prepared route is not a sufficient answer. ## 3. Inspect the package before import 1. Open the facilitator's manifest. Match solution/site names and versions to the source receipt. 2. Confirm the package does not include supplier records, credentials or source connection values. 3. Review the target worksheet: Nora environment, review team, training notification destination, site model and identity mapping. 4. The facilitator confirms whether site metadata travels in the selected solution model or through a separately prepared Power Pages artifact. Follow only that rehearsed path. **Expected:** every required component has a delivery artifact and a target binding. A table-only ZIP is not a complete portal. ## 4. Import into the target With the authorized training role, or alongside the operator where required: 1. Open Power Apps and choose **Nora's target environment** from the card. 2. Open **Solutions > Import solution**. 3. Select the reviewed package. Inspect the displayed name/version before proceeding. 4. At connection-reference prompts, the operator selects the target connections. Do not reuse a source credential or paste one into chat. 5. Enter target configuration values from the worksheet when prompted. If a value is not prompted, open the supplied configuration surface after import. 6. Complete import and open the import history/result. Preserve actual errors. 7. The facilitator applies the required site metadata/provisioning step and confirms the site remains private. **Expected:** the target has the right solution version and a functioning private site. A successful ZIP import alone is not the full checkpoint. ## 5. Verify missing-configuration behavior Use the facilitator's controlled test configuration, not a shared production setting: 1. Leave the Nora notification destination or review team unconfigured as directed. 2. Submit one designated training application. 3. Open the operator's validation/processing result. **Expected:** an explicit processing block and no notification to Zava's destination. Restore the correct target values through the supplied configuration surface and repeat the same test using the documented recovery path. Verify the target result rather than assuming the previous failed submission was replayed automatically. ## 6. Make the Nora rule change The beginner starter contains an optional **Service region** column, with North and South choices, plus a reviewed per-client **Require service region** validation setting. For Zava that field was not required or exposed. For Nora: 1. Open the designated development source, not the managed target. 2. Open the Supplier Submission form used by the portal. 3. Add Service region to the form, after Country. Save and publish. 4. In the prepared validation settings for the Nora configuration, set Require service region to Yes. 5. Have the operator package/deploy this approved version using the same rehearsed route. Bind the Nora setting in the target. 6. Sync the private target site through the prepared procedure. This is a deliberate beginner adaptation through an existing extension point. Creating an entirely new schema or server validator is an advanced extension, not an unexplained mandatory step. ## 7. Run the target acceptance cases 1. As Nora Supplier A, submit complete details with North. Verify one accepted review application. 2. Try a submission with no region using the facilitator's bypass fixture. It must not become accepted review work, even if an invalid source submission is retained as evidence. 3. As Supplier A try Supplier B's supplied record URL. No B data may appear. 4. As the Nora reviewer, inspect the application and team assignment. 5. Verify no Zava supplier/contact records or source notification destinations were imported. The facilitator runs any API/identity-sensitive bypass tests; learners record the actual identity, request and result. ## 8. Prove transfer without coaching The receiving consultant follows this recipe and the manifest independently. The source author observes without operating the mouse or supplying missing steps. Record questions and interventions. If a hidden dependency blocks progress, fix the manifest/runbook and repeat a fresh attempt. Do not reclassify a coached attempt as independent success. Return the actual import logs, configuration checks, Nora tests and intervention record to Cowork. Use the main lab's review and offering prompts. **Explain back:** what moved unchanged, what changed through configuration, and what would require specialist development for a real second client? The offering is a reproducible delivery package, not a claim that every deployment is identical. [END STANDALONE CONTEXT] Use guided build 10 and the actual source manifest. Explain which items are reusable components, which are configuration and which are customer records that must not travel. Walk through Nora's region requirement. Identify the exact prepared validation setting and form field; do not invent an export package or tell me to implement a plug-in. ``` **Expected:** a concrete mapping to the supplied assets. "Use the supported route" without naming the prepared route is not a sufficient answer. ## 3. Inspect the package before import 1. Open the facilitator's manifest. Match solution/site names and versions to the source receipt. 2. Confirm the package does not include supplier records, credentials or source connection values. 3. Review the target worksheet: Nora environment, review team, training notification destination, site model and identity mapping. 4. The facilitator confirms whether site metadata travels in the selected solution model or through a separately prepared Power Pages artifact. Follow only that rehearsed path. **Expected:** every required component has a delivery artifact and a target binding. A table-only ZIP is not a complete portal. ## 4. Import into the target With the authorized training role, or alongside the operator where required: 1. Open Power Apps and choose **Nora's target environment** from the card. 2. Open **Solutions > Import solution**. 3. Select the reviewed package. Inspect the displayed name/version before proceeding. 4. At connection-reference prompts, the operator selects the target connections. Do not reuse a source credential or paste one into chat. 5. Enter target configuration values from the worksheet when prompted. If a value is not prompted, open the supplied configuration surface after import. 6. Complete import and open the import history/result. Preserve actual errors. 7. The facilitator applies the required site metadata/provisioning step and confirms the site remains private. **Expected:** the target has the right solution version and a functioning private site. A successful ZIP import alone is not the full checkpoint. ## 5. Verify missing-configuration behavior Use the facilitator's controlled test configuration, not a shared production setting: 1. Leave the Nora notification destination or review team unconfigured as directed. 2. Submit one designated training application. 3. Open the operator's validation/processing result. **Expected:** an explicit processing block and no notification to Zava's destination. Restore the correct target values through the supplied configuration surface and repeat the same test using the documented recovery path. Verify the target result rather than assuming the previous failed submission was replayed automatically. ## 6. Make the Nora rule change The beginner starter contains an optional **Service region** column, with North and South choices, plus a reviewed per-client **Require service region** validation setting. For Zava that field was not required or exposed. For Nora: 1. Open the designated development source, not the managed target. 2. Open the Supplier Submission form used by the portal. 3. Add Service region to the form, after Country. Save and publish. 4. In the prepared validation settings for the Nora configuration, set Require service region to Yes. 5. Have the operator package/deploy this approved version using the same rehearsed route. Bind the Nora setting in the target. 6. Sync the private target site through the prepared procedure. This is a deliberate beginner adaptation through an existing extension point. Creating an entirely new schema or server validator is an advanced extension, not an unexplained mandatory step. ## 7. Run the target acceptance cases 1. As Nora Supplier A, submit complete details with North. Verify one accepted review application. 2. Try a submission with no region using the facilitator's bypass fixture. It must not become accepted review work, even if an invalid source submission is retained as evidence. 3. As Supplier A try Supplier B's supplied record URL. No B data may appear. 4. As the Nora reviewer, inspect the application and team assignment. 5. Verify no Zava supplier/contact records or source notification destinations were imported. The facilitator runs any API/identity-sensitive bypass tests; learners record the actual identity, request and result. ## 8. Prove transfer without coaching The receiving consultant follows this recipe and the manifest independently. The source author observes without operating the mouse or supplying missing steps. Record questions and interventions. If a hidden dependency blocks progress, fix the manifest/runbook and repeat a fresh attempt. Do not reclassify a coached attempt as independent success. Return the actual import logs, configuration checks, Nora tests and intervention record to Cowork. Use the main lab's review and offering prompts. **Explain back:** what moved unchanged, what changed through configuration, and what would require specialist development for a real second client? The offering is a reproducible delivery package, not a claim that every deployment is identical.