Permissions
Part of No-code governance
Reviewing citizen-developed apps before production use
Use a release brief, evidence table and decision record to review staff-built apps before colleagues rely on them.
Before colleagues depend on a staff-built app, decide whether evidence about the task, data, access, connected actions and support owner supports its proposed use. Record a decision to release, release to a limited group, return for changes or hold. State the accepted scope and the reason for any condition.
Request a short release brief
The maker should describe the users, the task they complete and the process the app will change. Name the business owner who can settle workflow rules. List the approved data sources and destinations, files, exports, notifications and systems the app may change. Identify the intended user roles, the account behind each connected action and the person who can maintain the app after release.
Include what happens when information is missing, a connected action fails or the maker is unavailable. For a hypothetical equipment handover app, the normal task might record a transfer and a recipient's confirmation; an exception might be a disputed confirmation.
Match evidence to the consequence
| Review area | Evidence to request | Reason to hold |
|---|---|---|
| Business task | Named owner, roles and agreed finish state | Nobody can decide whether the result is correct. |
| Data | Approved fields, sources, destinations and retention route | The app goes beyond its approved purpose. |
| Access | Intended grants and results for relevant ordinary-account checks | Protected records are reachable or essential users are blocked. |
| Connected actions | Confirmed source-system outcomes and a failure route | A write can appear successful without confirmation. |
| Operations | Maintainer, fault contact and recovery route | The team cannot support the live task. |
Set the depth of review to the likely consequences. A restricted trial with fictional records does not, by itself, approve later use with real customer data. For an app that handles personal information, consider asking the organisation's privacy reviewer to assess the planned collection, use and disclosure.
Ask the privacy reviewer whether a fuller privacy impact assessment is needed for the planned handling of personal information.
Evaluate checks already performed
For each material check, ask for the app version, account role, safe record identifier, expected result and observed result. Evidence should cover an ordinary task, a meaningful exception and a denied route where access matters. Compare the screen with the stored record and any connected-system result. A hidden menu item alone does not establish that a protected record is inaccessible.
Mark a check unresolved when it could not be run or its result could not be confirmed. A test setting may differ from production in ways relevant to security testing; state that limit beside evidence from a test setting.
Record the release decision
State what was accepted, the users and data covered, the open issues, required changes and their owners. A limited release needs a clear boundary and another decision point. A hold should identify the missing evidence or unacceptable outcome.
After release, record the app's owner, approved scope and review date in the organisation's inventory. Reopen the decision if its purpose, sharing, data or connected actions change.
