Skip to content

Support model for worker-built apps

A support model for citizen-developer and other worker-built apps says who fixes what at each risk tier. Support follows the risk tier, through four support levels. Sandbox apps are self-supported. Team apps are team-supported by the builder plus a champion. Important apps get assisted support: help-desk routing to the owner from the registry, a documented runbook and a named backup who has actually run the app. Critical apps are IT-supported under normal service levels. The help desk routes problems; it doesn't fix an app's logic.

Who this is for

IT managers, help-desk leads and app owners deciding who answers when an employee-built app breaks. You get the support levels side by side, a help-desk routing script, what users should see, capacity limits and the escalation path. Reading time: about 8 minutes.

What does each support level promise?

The tier sets the level; the gate matrix is the source for what each level requires. The columns beyond that are suggested starting points. Nothing here has been measured, so adjust them to what your owners and backups can really staff.

Hypothesis to test

We expect that four support levels, tied to the four risk tiers, are enough to route support for a typical business (A-018). Test this in your pilot: count the support requests that don't fit a level, and the number of apps whose owner says they can't staff the level their tier gives them.

Risk tier Support level Who answers When Suggested response expectation Escalation What IT will and won't do
Sandbox Self-supported The builder Whenever the builder is available None. The app is personal and time-boxed None Won't fix it. Provides the platform and the 90-day quarantine and deletion rules
Team Team-supported The builder plus a champion Business hours, best effort Acknowledge within the working week; users work around it meanwhile App owner, then the enablement lead Fixes platform and sign-in problems only. Won't debug the app's logic or data
Important Assisted The app owner, with a named backup who has run the app, using the runbook Business hours Acknowledge within one business day; the backup covers when the owner is away App owner, enablement lead, then the IT/platform owner Routes tickets from the registry; fixes platform issues; provides a technical reviewer for changes. Won't take over the app's logic
Critical IT-supported IT or engineering, with the business app owner IT's standard service hours and on-call rules IT's normal service levels IT's standard incident process Runs and fixes it as a co-owner after graduation; until then, see "A Critical app waiting for IT" below

A Critical app waiting for IT. Until graduation is done, a Critical app gets assisted support plus the scope cap (no new users, data or permissions), and its incidents go straight to IT's incident process and the security reviewer, not to the owner's queue. It doesn't wait in limbo, and IT doesn't absorb it informally.

Someone has to notice when it stops. Support above is reactive. Important apps also need a basic health check or a failure alert that reaches the owner and the backup (production ready, operations), so users aren't the monitoring. The response expectations are the same for every Important app only as a starting point: the owner sets a faster one where the Q4 answer is © because a process stops or outside people depend on it. Treat both as hypotheses, and time real responses in the pilot.

The difference between Team and Important is concrete: at Team, the builder and a champion answer when they can, and no one promises more; at Important, a named backup has run the app from a written runbook, and the help desk knows whom to route to.

Don't: promise IT support for everything

A support model that silently assumes IT absorbs every app turns the help desk into the maintainer of apps it never saw. Support follows the tier; below Critical, the owner is accountable (AP19)1.

Don't: set service levels nobody can staff

A response time that the owner and backup can't meet is a promise that fails on the first holiday. Set it to what the people named can do, and record who covers absences.

Don't: route support to a builder who has left

Help-desk routing reads the owner and backup from the app registry. If the registry names a departed builder, the routing sends tickets nowhere. Run the orphan check monthly (when the builder leaves).

Don't: name a backup who has never run the app

A backup who has never run the app is a name on a list. Before an app goes live at Important, have the backup run it once from the runbook with the builder watching.

How does the help desk route a ticket?

  1. Ask for the app's name or address. Users often don't know which tool built it.
  2. Look it up in the registry. Read the owner, backup, support level and platform.
  3. Route by support level. Self-supported: if the person calling isn't the builder, someone other than the builder is using it, so it's no longer Sandbox. Log it and send it to the enablement lead to register it. Team-supported: send to the team's queue or champion. Assisted: assign to the owner's queue and copy the backup. IT-supported: use IT's standard incident process.
  4. If the app isn't in the registry, log it as an unregistered app and send it to the enablement lead. Don't fix it.
  5. Fix only what the desk owns: access, sign-in, platform outages. Don't change the app's logic or data.
  6. Close with the owner. The owner confirms the fix and updates the record if anything changed.

Security incidents skip this script and go to incident response.

What do users of a worker-built app see?

Every app shows the same short banner or footer, filled in from the registry:

This is a worker-built app. Owner: role. Support: link to the support page.

It tells users who answers, and it tells everyone else the app isn't an IT product unless it says so. Automations, scheduled jobs, macros and agents often have no screen: put the same line in the footer of every message they send, and in the job's description field.

What are the limits on support capacity?

Support is limited by the people named, not by the policy. Keep these limits in view.

  • Owners and champions have a day job. The support level is only real if their manager has agreed the time (the roles page covers the manager's part).
  • The queue belongs to the owner. The help desk doesn't hold a backlog for apps; it routes.
  • Repeated escalations are a signal. If an app keeps reaching the enablement lead or IT, or the owner can't staff the level the tier gives, review the tier and the graduation triggers. Vendor guidance gives the same reason for a graduation path: makers overwhelmed by supporting critical solutions can't build new ones2.
  • Critical apps need IT capacity. If IT can't take a Critical app in time, its scope is capped until it can (Critical means co-ownership).

Who do I escalate to?

Builder or champion, then the app owner, then the enablement lead, then the IT/platform owner; the security reviewer for anything security-related; then the executive sponsor when two of them disagree or capacity is the bottleneck. The full path, including separation of duties, is on roles and decision rights.

Routing isn't free: the help desk's triage time is a real IT cost. Count the tickets routed at each support level every quarter, and report the count with the program's measures.

Record your support commitments

Record your support commitments once, using the decision record template.

Illustrative composite

Title: Support commitments for worker-built apps · Status: accepted · Date: YYYY-MM-DD · Owner: IT manager (a role)

Context. Staff-built apps are in use and the help desk gets tickets for them with no route to an owner.

Decision. Adopt four support levels tied to the risk tiers. The help desk routes from the registry, fixes access and platform problems only, and escalates security issues to incident response. Important apps need a runbook and a backup who has run the app before go-live.

Alternatives considered. IT supports every app (rejected: IT can't staff it and owners lose accountability). No support commitments (rejected: tickets go nowhere). A service-level agreement per app (rejected for now: nobody can staff it).

Consequences. Owners have named duties. We review the response expectations after the first quarter against what owners could actually do.

Review by: six months from the date above.

Assumptions and evidence

  • A-018 (Medium): we expect an objective four-tier model, with support tied to the tier, to be enough to route support, review and graduation for a typical business; test this by counting tier disputes and requests that fit no level.

Evidence: vendor support guidance2 and public-sector policy3, neither tested outside its own ecosystem, and an OWASP risk entry. The response expectations on this page are suggestions, not measured. Facts on this page are as of October 2026.

  1. OWASP Citizen Development Top 10, CD-SEC-09 "Asset Management Failures" (2022; the orphan risk persists). https://owasp.github.io/www-project-citizen-development-top10-security-risks/content/2022/en/CD-SEC-09-Asset-Management-Failures [primary], accessed 2026-10-21. ↩

  2. Microsoft, "Support strategy for solutions" (2025-05-14): three kinds of apps with matching support and a graduation path; makers overwhelmed by supporting critical solutions can't innovate. https://learn.microsoft.com/en-us/power-platform/guidance/adoption/support-strategy-solutions [vendor], accessed 2026-10-21. ↩↩

  3. Government of Saskatchewan, low-code/no-code development and maintenance policy (issued May 2026): IT maintains functionality touching sensitive data classes, public or multi-ministry reach, or core processes. https://taskroom.saskatchewan.ca/-/media/project/taskroom/documents/policy/lowcodenocodedevelopmentandmaintenancepolicy.pdf [primary], accessed 2026-10-21. ↩