Citizen Development Standards

Citizen development standards define the rules, constraints, and obligations that apply to staff who build technology solutions using low-code platforms without formal software development training. These standards establish what citizen developers are permitted to build, how they must build it, and what ongoing responsibilities accompany solution ownership. IT staff use this reference to evaluate citizen-built solutions and enforce compliance; citizen developers use it to understand their boundaries and obligations before beginning work.

For the rationale behind these standards and the governance structures that support them, see Low-Code Platform Governance.

Citizen Developer Definition

A citizen developer is any staff member who creates automated workflows, applications, integrations, or data solutions using low-code or no-code platforms while holding a primary role outside IT or software development. Programme officers building KoboToolbox automations, finance staff creating Power Automate workflows, and fundraising coordinators maintaining Airtable bases all qualify as citizen developers regardless of their technical proficiency.

The classification depends on role, not skill. A staff member with computer science training who works as a programme manager and builds Power Apps solutions remains a citizen developer under these standards. The distinction matters because citizen developers operate under different governance requirements than IT development staff, with additional constraints on solution complexity, data handling, and integration scope.

Registration Requirements

All citizen developers must register with IT before creating solutions. Registration establishes accountability, enables IT oversight, and ensures solutions receive appropriate support classification.

Registration does not grant automatic approval for specific solutions. Each solution of moderate or higher complexity requires separate approval through the solution approval process detailed in the Solution Lifecycle section.

Permitted Platforms

Citizen development is restricted to platforms that IT has evaluated for security, data governance, and supportability. Using unapproved platforms for organisational data constitutes a policy violation regardless of the solution’s utility.

Platforms not listed above require formal evaluation through IT before use. Evaluation takes 15-30 working days depending on complexity. Staff may not use trial accounts on unevaluated platforms with organisational data.

Platform-Specific Constraints

Each permitted platform carries specific constraints beyond the general requirements in this document.

Microsoft Power Platform operates within the organisation’s tenant and inherits its security configuration. Citizen developers may not create custom connectors, use premium connectors without IT approval, or deploy solutions outside the default environment. Power Automate flows connecting to external services require security review when processing any personal data.

Airtable bases containing more than 10,000 records or connecting to external services via automations require IT registration as moderate-complexity solutions. Sync integrations with other platforms require explicit approval. Bases must use Airtable’s organisation workspace rather than personal workspaces.

KoboToolbox deployments for beneficiary data collection require data protection impact assessment completion before field deployment. Encryption at rest must remain enabled. Data exports must follow the data handling requirements specified in this document.

Zapier and Make automations that transfer data between cloud services require documentation of data flows and approval when any personal data is involved. Multi-step workflows exceeding 10 steps require IT review before activation.

Use Case Classification

Solutions fall into three complexity categories that determine approval requirements, documentation obligations, and review frequency. The classification depends on data sensitivity, integration scope, user count, and operational criticality.

Simple Solutions

Simple solutions automate personal or small-team tasks without processing personal data or connecting to systems of record.

Examples include personal task automation, team scheduling tools, simple calculators, and document generation from templates that contain no personal data.

Moderate Solutions

Moderate solutions serve broader user groups, process limited personal data, or integrate with approved external services.

Examples include departmental request tracking, team dashboards pulling from approved data sources, expense pre-approval workflows, and leave request automation.

Complex Solutions

Complex solutions approach the threshold where professional development becomes appropriate. These solutions require substantial IT involvement and may warrant transition to IT-managed development.

Complex solutions require a named IT contact who shares accountability for security and data handling. If a proposed solution exceeds complex thresholds, IT will recommend professional development rather than citizen development.

Prohibited Patterns

Certain solution types and integration patterns fall outside citizen development scope regardless of the developer’s capability.

Prohibited Solution Types

The following solution categories require professional IT development:

• Solutions processing payment card data or bank account details
• Authentication or identity management systems
• Solutions storing credentials, API keys, or secrets outside platform-provided secure storage
• Public-facing applications or portals accessible without organisational authentication
• Solutions processing special category data under GDPR (health, biometric, political, religious, trade union, sexual orientation, criminal records) without explicit IT approval
• Mobile applications distributed outside enterprise app stores
• Solutions intended to replace or significantly extend systems of record

Prohibited Integration Patterns

Citizen developers may not implement the following integration patterns:

• Direct database connections to production systems
• Screen scraping or robotic process automation against systems without API access
• Integrations using service accounts with administrative privileges
• Webhook endpoints receiving data from external systems without validation
• Bidirectional sync between systems of record
• Integrations that bypass audit logging

For integration patterns that are permitted, see API Integration Patterns.

Prohibited Data Handling

Data handling restrictions apply regardless of solution complexity:

• Downloading beneficiary data to personal devices
• Storing personal data in platform features lacking appropriate access controls
• Transferring data to platforms not approved for that data classification
• Disabling or circumventing platform audit logging
• Sharing access credentials rather than using platform permission features
• Exporting data to file formats that cannot be encrypted (plain CSV for confidential data)

Naming Conventions

Consistent naming enables IT oversight, simplifies support, and clarifies ownership. All citizen-built solutions must follow the naming convention for their platform.

Standard Naming Format

[Dept]-[Type]-[Function]-[Version]

Complete examples:

• FIN-WFL-ExpensePreApproval-v1 (Finance workflow for expense pre-approval)
• PRG-FRM-BeneficiaryIntake-v2 (Programme form for beneficiary intake, second version)
• FND-DSH-DonorPipeline-v1 (Fundraising dashboard for donor pipeline)
• HRS-APP-LeaveRequest-v3 (HR application for leave requests)

Platform-Specific Naming

Some platforms impose character limits or format restrictions:

Deviations from naming conventions require IT approval and documentation explaining the constraint.

Data Handling Requirements

Citizen developers assume data controller responsibilities within their solutions. These requirements ensure solutions meet organisational data protection obligations.

Data Classification Compliance

Every solution must document its data classification and handle data according to classification requirements. The classification derives from the most sensitive data element the solution processes, not the average sensitivity.

Data classification definitions and handling requirements appear in Data Classification.

Personal Data Processing

Solutions processing personal data must document:

• Legal basis for processing (consent, contract, legitimate interest, legal obligation)
• Data subjects affected (staff, beneficiaries, donors, partners)
• Personal data elements collected or processed
• Retention period and deletion mechanism
• Access control implementation

Solutions processing beneficiary personal data require a Data Protection Impact Assessment (DPIA) before deployment. The DPIA process is documented in Privacy by Design.

Data Retention

Citizen-built solutions must not retain data beyond defined retention periods. Platform features for automatic deletion must be configured where available. Where automatic deletion is unavailable, the solution owner must perform manual deletion according to the retention schedule.

Data Export and Backup

Solutions classified as moderate or complex must support data export in a format that enables migration to alternative platforms. This requirement ensures organisational data remains accessible if the platform becomes unavailable or the citizen developer leaves.

Export capability must be tested during initial deployment and verified during each review cycle. Exports must use formats appropriate to data classification (encrypted archives for confidential data).

Security Requirements

Security requirements scale with solution complexity and data sensitivity. All citizen-built solutions must meet baseline security requirements; additional requirements apply to moderate and complex solutions.

Baseline Security (All Solutions)

Every citizen-built solution must implement:

• Platform-native authentication only (no custom authentication)
• Access restricted to users who require it
• Default-deny permission model (users have no access until explicitly granted)
• Audit logging enabled (where platform supports)
• Solution accessible only via organisational accounts (no personal account access)

Additional Security for Moderate Solutions

Solutions classified as moderate must also implement:

• Role-based access control with documented role definitions
• Activity logging sufficient to investigate misuse
• Automated session timeout (maximum 8 hours)
• No storage of credentials in workflow steps (use platform credential stores)

Additional Security for Complex Solutions

Solutions classified as complex must also implement:

• Annual access review with documented recertification
• Data encryption at rest (platform-provided)
• Incident response contact identified and documented
• Penetration testing or security review before deployment (IT-coordinated)

Secrets and Credentials

Citizen developers must never embed credentials, API keys, tokens, or passwords directly in solution configurations. All platforms provide secure credential storage; these features must be used exclusively.

When integrating with services not supported by platform connectors, request IT assistance rather than using embedded credentials.

Documentation Requirements

Documentation ensures solutions remain maintainable when developers change roles or leave the organisation. Requirements scale with solution complexity.

Simple Solution Documentation

Simple solutions require a solution registration record only:

Moderate Solution Documentation

Moderate solutions require a solution specification document (2-4 pages) containing:

Complex Solution Documentation

Complex solutions require moderate documentation plus:

Documentation must be stored in a location accessible to IT and the solution owner’s manager. Recommended locations include SharePoint document libraries or internal wikis with appropriate access controls.

Solution Lifecycle

Citizen-built solutions progress through defined lifecycle stages with specific activities required at each stage.

Development and Approval

+---------------+     +---------------+     +---------------+
|               |     |               |     |               |
|   Register    +---->+   Develop     +---->+   Submit for  |
|   as Citizen  |     |   Solution    |     |   Approval    |
|   Developer   |     |   (sandbox)   |     |               |
+---------------+     +---------------+     +-------+-------+
                                                    |
        +-------------------------------------------+
        |
        v
+-------+-------+     +---------------+     +---------------+
|               |     |               |     |               |
|   IT Review   +---->+   Implement   +---->+   Production  |
|   (if req'd)  |     |   Feedback    |     |   Deployment  |
|               |     |               |     |               |
+---------------+     +---------------+     +---------------+

Figure 1: Solution development and approval flow

Sandbox development is mandatory. All platforms provide sandbox or development environments where solutions must be built and tested before production deployment. Deploying untested solutions directly to production violates these standards.

Approval routing depends on classification:

• Simple: Self-service deployment after registration verification
• Moderate: IT review via service desk ticket (10 working days)
• Complex: IT architecture review via formal request (20 working days)

Ongoing Maintenance

Production solutions require ongoing maintenance regardless of stability:

Review and Audit

IT conducts periodic reviews of citizen-built solutions to verify compliance with these standards.

Solutions failing compliance review receive a remediation deadline based on severity:

Handover Requirements

When a citizen developer leaves the organisation, changes role, or can no longer maintain a solution, handover must occur within 20 working days of the triggering event.

Handover package contents:

The departing developer’s manager is responsible for ensuring handover completion. If no suitable recipient exists within the team, IT assumes temporary ownership and evaluates whether the solution should continue.

Retirement

Solutions no longer needed must be formally retired rather than abandoned. Retirement ensures data is handled appropriately and platform resources are released.

Retirement process:

1. Solution owner submits retirement request via IT service desk
2. IT verifies no active dependencies
3. Data exported and archived per retention requirements
4. User access removed
5. Solution disabled (not deleted) for 90-day recovery window
6. Solution permanently deleted after recovery window
7. Documentation archived

Solutions that have had no activity for 12 months trigger automatic retirement review. Owners must confirm continued need or initiate retirement.

Escalation to Professional Development

Some solutions exceed the appropriate scope for citizen development even when technically feasible on low-code platforms. Escalation to professional development protects the organisation and the citizen developer from unsupportable solutions.

Escalation Triggers

Any of the following triggers escalation to IT for professional development assessment:

• Solution exceeds complex classification thresholds
• Solution requires prohibited patterns or integrations
• Solution replaces or significantly modifies a system of record
• Three or more significant incidents within 6 months
• Maintenance burden exceeds 8 hours per month
• Solution owner unable to explain how the solution works
• External audit or compliance requirement mandates professional oversight
• Integration with systems not supporting low-code connectors

Escalation Process

+---------------+     +---------------+     +---------------+
|               |     |               |     |               |
|   Trigger     +---->+   IT          +---->+   Assessment  |
|   Identified  |     |   Notified    |     |   Meeting     |
|               |     |               |     |               |
+---------------+     +---------------+     +-------+-------+
                                                    |
                      +-----------------------------+
                      |
        +-------------+-------------+
        |                           |
        v                           v
+-------+-------+           +-------+-------+
|               |           |               |
|   Remediate   |           |   Transition  |
|   as Citizen  |           |   to IT       |
|   Solution    |           |   Development |
|               |           |               |
+---------------+           +---------------+

Figure 2: Escalation decision flow

Assessment meeting includes the citizen developer, their manager, and IT representative. The meeting evaluates whether remediation within citizen development scope is feasible or whether transition to professional development is required.

Transition to IT development follows the organisation’s standard project intake process. The citizen developer typically remains involved as subject matter expert but no longer holds development responsibility. Existing solution continues operating under IT oversight during transition.

Compliance Verification Checklist

Citizen developers should verify compliance before requesting solution approval. IT uses this checklist during reviews.

See Also

• Low-Code Platform Governance
• API Integration Patterns
• Webhook Configuration
• Data Classification
• Privacy by Design
• Low-Code Platforms