The Orphaned Lead Capture App
A marketing coordinator built a lead capture app for trade shows using a canvas app, a Power Automate flow and a workbook stored in her personal OneDrive. It collected 3,200 leads over 18 months: name, work email, phone, employer, and free-text notes that include comments about attendees' health and dietary needs. She left the company in March and her account was disabled in April, at which point the flows stopped running. Twelve field representatives still use the app; it now displays a success message while writing nothing. In June, a data-discovery scan found the workbook shared as anyone with the link. There is no entry for this app in any inventory, no named business owner, and at the time of creation the data loss prevention policy did not cover personal cloud storage connectors. Legal has asked for a full account of the data and how many people are affected.
1. Sequence the containment and recovery work. What must happen before anything is deleted?
Read the worked answer
Order matters here, and deletion is the last step, not the first.
- Preserve before removing: export or snapshot the workbook, the flow run history, the app definition and the list of sharing links. Legal's question about how many people are affected requires the record that is about to be deleted to answer it. Destroying evidence, even with good intentions, turns a technical incident into a legal problem.
- Contain access: revoke the anonymous sharing link and any other external shares immediately; this is the only step that should precede preservation if the exposure is active. Confirm whether the link was actually accessed by reviewing the sharing and audit logs - that determines whether a notification obligation is triggered.
- Reconcile the lost data: the app has been showing a success message while writing nothing, so submissions since April may exist nowhere. Check flow runs and any local device caches for rep submissions, and tell the field team to stop using the app immediately and forward anything they captured by other means.
- Restore service on an approved store: migrate the 3,200 records to a governed site with retention and permissions, rebuild the flow under a service account or shared mailbox, re-point the app, and verify end to end with a test submission before announcing.
- Assess the data: classify the free-text health-related notes as sensitive. That raises both the risk tier and the notification analysis. Legal and privacy decide, not the maker.
- Decommission and record: retire the personal OneDrive copy only after the migration is verified, and document the disposal.
2. What were the governance failures, and which controls would have prevented each one?
Read the worked answer
Work backwards from the symptoms, because each one maps to a missing control.
- No inventory entry -> a registration requirement at intake. Any app handling personal data should be recorded with owner, data classification, platforms used and audience. The inventory is also what makes an app discoverable rather than something IT finds in a scan.
- No business owner -> ownership assigned to a role and a group, not an individual, with a named business sponsor accountable for the app. Individual ownership guarantees orphaning at the next job change.
- Account disabled, flows stopped, nobody noticed for two months -> an offboarding checklist that includes a search of the leaver's Power Platform and flow assets, plus a scheduled ownership attestation that flags apps with an inactive owner.
- Personal OneDrive as a data store -> DLP policy covering personal storage connectors, and an approved-store rule at intake. The policy gap is now closed, but the exception process and a communication plan matter as much as the block, or users will find another route.
- Sensitive free text -> a data classification gate before build. Health-related notes should have triggered review and probably a redesign of the free-text field.
- Silent failure with a success message -> a monitoring expectation proportional to risk tier: critical flows need an alert on failure and a UI that reports the truth.
Presentation matters. If the response is framed as a crackdown, the next marketing app will be built and simply not registered. Frame it as intake that is fast for low-risk apps and thorough only for high-risk ones.
3. Design a proportionate intake and risk-tiering model, and explain how the citizen developer program should work with IT and legal from here.
Read the worked answer
Proportionality is the whole design. A single heavy review for every app will be bypassed within a month; the goal is that low-risk apps get a same-day yes.
Tier 1 - low risk: no personal data, audience under 50, no system of record. Self-service registration, standard environment, no review gate. Most apps live here and should move fast.
Tier 2 - moderate: internal personal data, or an approval process with budget impact. Lightweight review by the center of excellence covering data store, ownership and support route; a 30-minute review, not a project.
Tier 3 - high: sensitive data, external sharing, regulated records, or more than a few hundred users. Full review with IT security, privacy and legal before build, plus defined monitoring, ALM and exit plan. The lead capture app belongs here.
The intake form should ask four questions that determine the tier: what data, who sees it, who relies on the output, and what happens if it stops working.
Working with IT and legal: publish the tiers and the criteria so the answer is predictable; commit to turnaround times; give the CoE authority to approve Tier 1 and 2 without ticket queues; run a monthly inventory review with business owners attesting their apps are current; and route privacy questions to legal through a single channel rather than ad hoc emails. Finally, run a 30-minute briefing for the field marketing team explaining what went wrong and what to do next time - the goal is to keep the people who build useful things, while making sure the organization knows they exist.