A service request desk is a useful first Copilot Code project because its result is easy to check: find a request, assign it, save an update, reopen it, and confirm the same values in SharePoint. This companion helps you repeat the small pilot shown in EP023 and record the decisions around it.
Lab date: October 29, 2026. Products: Microsoft Copilot Code (Frontier preview), Copilot Managed Runtime (preview), SharePoint and Power Platform admin center. Environment: one Microsoft 365 demo tenant; the app was correlated to a managed personal Developer environment. These are dated observations, not a promise of availability in every tenant.
What the sample does
The fictional Juniper Service Request Desk reads 60 synthetic requests. Users can search request keys, titles and summaries; filter by site, priority and status; and see total, open, overdue and unassigned counts. A detail panel lets them assign work and edit status, an update note or a resolution note. Resolving a request requires a resolution note. Save writes to SharePoint, then rereads the saved record.
The scope is deliberately small: no new requests, deletion or email delivery. Restricting which fields the interface displays does not create a security boundary. The app still needs an appropriate connection and source permissions.
Start with the versioned practice pack
Download the Juniper Service Request Desk starter pack v1.1.
The ZIP contains a README, 60-row CSV and JSON, an Excel import workbook, a field map, the full build prompt, expected results and an admin checklist. It contains synthetic data only and is a starting point for building your own app, not a deployable app package. Read the README before importing the workbook into a dedicated demo SharePoint list.
Keep the field names aligned with the field map and preserve date-only values as ISO text where specified. The example uses a fixed October 29, 2026 cutoff for reproducible overdue totals. Before editing anything, expect 60 total requests, 48 open, 20 overdue and 12 unassigned. Assigning the demonstration request reduces unassigned to 11; the other totals stay the same. If your import or initial totals differ, fix that before asking the app to update records.
Check access and funding before building
Start with the person who will use Code. Check the current product requirements, tenant availability and policy coverage. Microsoft's documented access-request experience is conditional: an uncovered user may see Request access when discovery and requests are enabled, while Learn More can appear when requests are disabled. This lab did not reproduce the denied-access path.
In the cost management center, review these decisions with the policy owner:
| Decision | What to record |
|---|---|
| Policy name | A clear pilot or team name, owner and purpose; avoid a name that hides an organization-wide scope. |
| People and groups | The intended users, group membership and any overlapping policies that need review. |
| Enabled services | Confirm both the Code and Copilot Managed Runtime services needed for this scenario; inspect any automatic inclusion of future services. |
| Limits and thresholds | Record policy and user limits, the intended response when they are reached, and who can change them. |
| Alerts | Check recipients, thresholds and response ownership; a monitoring page alone does not prove alerts are configured. |
| Azure funding | For pay-as-you-go, confirm the intended Azure subscription and associated billing setup, resource group and finance owner. |
The episode inspects the existing policy and funding configuration without saving changes. Values visible in that tenant are not recommended universal limits. Tenant credit totals are not a measured cost for this app. An Azure budget notification is distinct from an enforced spending restriction; verify which control you are actually relying on.
Build around observable acceptance criteria
Use the supplied prompt to describe the list, fields, filters, sorting, editing rules, validation and deliberate Save behavior. Ask for a useful result with explicit boundaries. Keep permissions and data authorization in the source and platform controls rather than relying on instructions in a prompt.
After the first build, use a short test sequence:
- Confirm the four baseline counts against the imported list.
- Search for a known request and combine filters.
- Change one permitted field, save, reopen the record and inspect the source list.
- Check the resolution-note requirement.
- Open the published app with an intended non-admin user using that user's own connection.
The creator and the existing SK non-admin account passed the positive tests shown in the episode. SK's temporary update was restored afterward. The recording also preserves an actual transient save display: the confirmation toast and a brief prior-value display during the reread. Successful persistence does not mean every aspect of the preview interface is polished.
Find the app after creation
Open the published app from Apps and record its identity, owner and environment. Correlate that same app in the admin inventory before inspecting its connectors and monitoring surface. An Active inventory entry is not, by itself, proof that the intended release is live.
App sharing and source-data permissions need separate checks. In this pilot the non-admin user had app access and edit access to the dedicated synthetic SharePoint list, with its own SharePoint connection. That positive result does not prove denied-access enforcement.
Understand the environment and routing
The episode identifies the actual environment used by this app and inspects the existing Managed Runtime routing configuration. It does not create a new routing rule or demonstrate every maker/routing combination. Record the environment type, management status, group membership and routing decision relevant to your tenant before widening access.
Use the current Managed Runtime routing documentation for planning. Do not assume that a conventional canvas-app or solution deployment procedure applies unchanged to an app created in Code. A dedicated follow-up can examine routing choices and their consequences without crowding the first build.
Release, verify and assign ownership
The lab's lifecycle sequence is a useful acceptance lesson: a completion banner initially left the earlier live header visible. The final v1.1 view was verified separately in a fresh app view with the expected counts. Check the actual live result rather than treating an assistant response or build completion message as your release evidence.
For a wider pilot, assign a business owner, technical owner and support contact. Record the data source, connections, intended audience, spending owner, environment and acceptance evidence. Define review gates for access, data handling, functional checks, release verification and recovery. Keep the build prompt and change history, then investigate the recovery and deployment capabilities actually supported by the product before promising rollback or automated promotion.
Not verified in this lab: denied access, missing knowledge, concurrent edits, rollback and solution pipelines. These are follow-up work, not passed tests. The checklist is a planning aid and does not establish production readiness or a completed security assessment.
Primary sources and corrections
Microsoft documentation checked for the episode on October 29, 2026:
- Copilot Code requirements (opens in a new tab)
- Use Copilot Code (opens in a new tab)
- Manage Copilot Code (opens in a new tab)
- Copilot Credit policy management (opens in a new tab)
- Usage-based billing setup (opens in a new tab)
- Access requests (opens in a new tab)
- Managed Runtime administration (opens in a new tab)
- Managed Runtime environment routing (opens in a new tab)
- Azure budgets (opens in a new tab)
Version 1.0. No corrections recorded at release. Future dated corrections will appear here. Juniper Field Services is fictional. The video uses Tunde's authorized AI avatar and synthetic voice. This is an independent tutorial, not Microsoft certification or endorsement.
