CD Consulting R&D

KB-DEV · Entry 3 · Published 9 September 2026 · Version 1

An AI-use request register on Microsoft 365, with standard connectors only

From form to management report in about an hour of clicks - specification, build guide, corporate deployment checklist, and the pitfalls met on the way.

If you must show who uses generative AI before the AI Act asks, this register takes an hour of clicks and no premium licence.

Specification, build guide and deployment notes, condensed and anonymised from an internal prototype package on 9 September 2026. Sources consulted 9 September 2026.

Contents

1. 1. The use case
2. 2. Architecture: four roles, all standard
3. 3. Data dictionary
4. 4. The two flows
5. 5. The rules
6. 6. Build guide, about an hour of clicks
7. 7. Moving it to a corporate environment
8. 8. V2 hooks, laid out but not built
9. 9. Method and provenance
10. 10. Sources

1. The use case

A user declares a request to use generative AI (Copilot or another tool): who they are, what they want to do, with which tool, by when — and where the EU AI Act verification stands. Requests are stored; a periodic report on criteria goes to management. The value demonstrated is twofold: traceability of AI usage, and a compliance entry point — article 4 of the AI Act makes "AI literacy" an obligation for providers and deployers, and a register of uses is the natural first artefact [S6].

2. Architecture: four roles, all standard

3. Data dictionary

The prototype was built with French display names (rename at will); internal names are ASCII without spaces — a SharePoint rule worth respecting from the first click, because the internal name is frozen at creation while the display name can be changed at any time.

4. The two flows

Flow A — "request created" (trigger: When an item is created): compose the DEM-YYYY-ID reference and write it into Title; send an acknowledgement mail to the requester; and if the requested production date falls within 14 days OR the declared classification is high-risk, send an immediate alert to management. Otherwise nothing — the request waits for the periodic report.

Flow B — "report to management" (trigger: Recurrence, weekly; run manually for demos): read the items where StatutDemande equals "Nouvelle"; build an HTML table plus counters (total, AI Act "to do", production within 30 days); mail the report; then switch every reported item to "Rapportée".

5. The rules

• Form completeness: required fields non-empty, plausible mail, description of 30 characters minimum, production date not in the past — all blocked at input time in the app, so no invalid record ever reaches the store.
• Immediate alert: production requested within 14 days, or declared high risk.
• Report: every "Nouvelle" request, with AI Act "to do" and near-term productions highlighted.

6. Build guide, about an hour of clicks

Prerequisite: a Microsoft 365 account with SharePoint, Power Apps and Power Automate — the free M365 Developer plan is enough. Open make.powerapps.com and make.powerautomate.com first: if both studios open without a purchase prompt, everything below will go through.

Step 1 — the list (10 minutes by hand, 2 by script)

Either script it with PnP PowerShell [S5] — Install-Module PnP.PowerShell, then Connect-PnPOnline on the target site and one Add-PnPField per column of §3 — or create it by hand: SharePoint → New → List, then add each column, entering the ASCII internal name FIRST and renaming the display name afterwards.

Step 2 — the form (20 minutes)

Create → Start with data → the list: Power Apps generates a wired three-screen canvas app [S1]. On the edit form, set Title, StatutDemande and CodeApplicatif read-only (DisplayMode.View on their cards — they belong to the flows). Wire the validations: Required on the cards; !IsMatch(...Text, Match.Email) for the mail; Len(...Text) < 30 for the description; ...SelectedDate < Today() for the date; and the global lock on the submit button, If(<all conditions true>, DisplayMode.Edit, DisplayMode.Disabled).

Two pitfalls met here. First, put the lock on the BUTTON, not on the input: an input disabled until it reaches 30 characters can never receive them — a perfect deadlock, observed live. Second, in a French-locale studio Power Fx separates arguments with semicolons, not commas; formulas copied from English documentation arrive broken.

Step 3 — flow A (15 minutes)

Trigger When an item is created, then Update item (Title = concat('DEM-2026-', triggerOutputs()?['body/ID'])), Send an email (V2) to the requester, and a Condition (date within 14 days OR high risk) whose Yes branch mails a MailManagement variable. Pitfall met: the "Send an HTTP request to SharePoint" action speaks lightweight OData — no __metadata envelope in request bodies, unlike verbose browser-side REST.

Step 4 — flow B (15 minutes)

Recurrence → Get items with the filter query StatutDemande eq 'Nouvelle' → Select (the four report columns) → Create HTML table → Send an email (V2) → Apply to each over the items, updating StatutDemande to "Rapportée" (the standard Update item action, or an HTTP MERGE with IF-MATCH: * and X-HTTP-Method: MERGE headers and the static body {"StatutDemande":"Rapportee"}).

Step 5 — the demo (10 minutes)

Enter three fictitious requests — an ordinary one, one due within 14 days, one high-risk. Show the input blocks, flow A's two mails, then run flow B: the report arrives and the statuses flip. Restore the statuses afterwards, or the next report is empty.

7. Moving it to a corporate environment

The code is exportable three ways: a Power Platform Solution (unmanaged, app plus flows, connection references remapped at import — the recommended route) [S4]; the legacy Export package wizard, which works across tenants; or each flow alone. What travels is declarative and adjustable on arrival — Power Fx formulas in the studio, flow definitions in the designer.

There is more than code — four things. The SharePoint list is in no package: recreate it by script or by hand. The data does not travel. The connections are never exported — they are recreated with the target account, by design. And identifiers change at import: site, list and recipients must be re-pointed.

The target-environment checklist: maker rights in a Power Platform environment (often to be requested); DLP policies [S7] — the classic hard spot being the "Send an HTTP request to SharePoint" action, with the standard Update item action as a ready workaround; licences (seeded Power Apps/Automate in M365 suffices — standard connectors only); a SharePoint site where the list can be created; and, for the Solution route, Dataverse in the target environment.

8. V2 hooks, laid out but not built

Advanced cross-field validation; post-report actions (fetch a code by UserID from an API into CodeApplicatif, statuses moving to "En action" then "Clôturée"); the switch from the SharePoint list to SQL or Dataverse where premium licences exist; and a formal approval step (Approvals connector, standard) between report and action.

9. Method and provenance

This entry condenses an internal three-document package — specification, build guide, deployment note — written on 9 September 2026 while actually building and testing the prototype end to end on a development tenant: form validations exercised, both flows run against a 53-record fictitious dataset, report mail received and statuses verified by REST. Every pitfall flagged "met" above was hit and resolved during that build. All demo data was fictitious; tenant identifiers and live URLs have been removed from this public edition.

10. Sources

Consulted 9 September 2026.

1. S1 Microsoft Learn — Understand data forms in canvas apps (official documentation). https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/working-with-forms
2. S2 Microsoft Learn — SharePoint connector reference (official documentation). https://learn.microsoft.com/en-us/connectors/sharepointonline/
3. S3 Microsoft Learn — Standard and premium connectors in Power Platform (official documentation). https://learn.microsoft.com/en-us/power-platform/admin/power-automate-licensing/types
4. S4 Microsoft Learn — Solutions overview — export and import of apps and flows (official documentation). https://learn.microsoft.com/en-us/power-apps/maker/data-platform/solutions-overview
5. S5 PnP PowerShell — community-maintained SharePoint administration module (project documentation). https://pnp.github.io/powershell/
6. S6 Regulation (EU) 2024/1689 (AI Act), article 4 — AI literacy (official text, EUR-Lex). https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. S7 Microsoft Learn — Data loss prevention policies in Power Platform (official documentation). https://learn.microsoft.com/en-us/power-platform/admin/wp-data-loss-prevention

Limits: verified on a single development tenant in September 2026; studio labels, licence tiers and DLP behaviour move with Microsoft's release cycle and vary by organisation; the register is a prototype, not a governance process — classification fields are declarative and unreviewed.