Someone, somewhere in your organisation, built an AppSheet. Then someone else did. Then a third person, in Housing probably, built three. Now you have a small estate of tools that real people depend on, no version control, no documentation, and the creeping dread that one person leaving takes half of it down with them. We've been there. This playbook is what we built to get out of it. A practical operating model for teams that want engineering rigour without pretending they're a software house.

The AppSheet Playbook

1. Introduction

This playbook provides a structured, opinionated approach to building and managing Google AppSheet applications within UK local government. It is written for digital teams, software developers, IT governance leads, and anyone involved in delivering internal tools and resident-facing services using Google’s AppSheet platform.

This guidance draws on AppSheet’s official documentation, Google Workspace security and compliance frameworks, the UK Government’s Technology Code of Practice, and emerging practice from the cross-government low-code community. It treats AppSheet not as a toy for quick prototypes, but as a serious delivery platform that demands the same discipline around environments, testing, data protection, and deployment that you would apply to any other web application.

1.1 Who is this for?

This playbook is aimed at UK councils and local authorities that have adopted (or are evaluating) Google Workspace and want to use AppSheet to replace spreadsheet-driven data processes, digitise paper forms, build case management tools, or automate back-office workflows. The audience includes IT leads setting government policy, software developers building apps within service areas, and data protection officers assessing risk

1.2 Alignment with UK Standards

All guidance in this playbook should be read alongside:

• The Technology Code of Practice (TCoP) – the cross-government standard included in the Local Digital Declaration. While local authorities are not mandated to follow TCoP, it provides the baseline framework for technology decisions and is referenced thought this document.
• The Service Standard – applicable where AppSheet apps form part of a service delivered to residents or staff.
• UK GDPR and Data Protection Act 2018 – the legal framework governing all personal data processing within your apps.
• The Cross-Government Low-Code Community – a collaborative community promoting standards, best practice, and reuse across central and local government. Their shared GitHub repository and emerging standards work are directly relevant.
• The Local Government Association’s Cyber, Digital and Technology Guidance, including the code of practice for software vendors.

2. Data structure design

Getting the data model right is the single most important investment that you’ll make in an AppSheet project. A poorly structured spreadsheet will create compounding problems with performance, security filtering, reporting, and maintainability. AppSheet is fundamentally a data-driven platform. Your app is only as good as the data underneath it.

2.1 Core principles

One row, one record. Every table should follow a strict normalised structure where each row represents a single entity (a person, a case, an inspection, a booking) and each column represents a single attribute of that entity. Never store multiple values in a single cell. Never use columns as a time series (e.g. “Jan”, “Feb”, “Mar”). Use rows instead.

Every table needs a key. Each table must have a unique identifier column that serves as the primary key. AppSheet uses this to track, reference, and relate rows. Use the UNIQUEID() function or a computed key column rather than relying on row numbers, which are fragile and can change.

Use Ref columns for relationships. Connect tables using Ref (reference) columns that point to the key of a related table. This creates navigable parent-child relationships. For example, a “Cases” table might have a Ref column pointing to “Residents”, and a “Case Notes” table might have a Ref column pointing to “Cases”. AppSheet will automatically generate reverse references and related views.

Name columns clearly and consistently. Use descriptive, human-readable column names. Avoid abbreviations, generic names like “Column1”, and spaces where possible (use underscores or PascalCase). Bold your header row so AppSheet recognises it. Consistent naming across tables (e.g. always calling your key column [Row_ID] or [Record_ID] makes formulas and references more predictable.

Enforce data type consistency. Every cell in a column should contain the same data type. A “Date” column should never contain free text. A “Phone” column should use AppSheet’s Phone type, not text. Mismatched types cause silent errors in expressions and filters.

2.2 Normalisation for Local Government

Local government data tends to involve deeply interconnected entities: residents, addresses, properties, services, cases, officers, teams. Resist the temptation to flatten everything into a single massive spreadsheet.

A recommended baseline structure for a typical case management app might include:

• Residents – personal details, contact information (PII-flagged columns)
• Addresses – linked to Residents via REF, using UPRN where available
• Cases – linked to Residents, with status, category, assigned officer
• Case_Notes – linked to Cases, timestamped, with author
• Officers – linked to team/service area, email for security filtering
• Lookup tables – categories, statuses, service areas (used as Valid_If sources).

This separation means you can apply different security filters to different tables (e.g. officers only see their own cases), mark PII columns independently, and scale without hitting performance walls.

2.3 Lookup Tables and Controlled Vocabularies

Use dedicated lookup tables for any value that appears in a dropdown or categorisation. Do not hardcode lists of values in column Valid_If expressions. A lookup table means you can update the list of options without editing the app definition, and can reuse the same lookup across multiple apps.

Common lookup tables for local government contexts might be: service areas, case statuses, priority levels, ward names, committee names, building types, risk categories.

2.4 Google Sheets as a data source - Practical guidance

Google Sheets is the most common data source for AppSheet in a Workspace environment, but it has limitations that you must plan for:

• Row limits. Sheets performs well up to approximately 5,000-10,000 rows per table for most AppSheet use cases. Beyond this, consider AppSheet Database, Cloud SQL, or BigQuery as alternatives.
• Concurrent editing. Multiple users editing the same sheet outside the app can cause sync conflicts. Treat the sheet as a database. All writes should go through AppSheet, not into the sheet directly.
• Sheet structure. One sheet per table. Do not use multiple tabs in a single spreadsheet file as separate tables for an app. It creates tight coupling. Each table should live in its own spreadsheet file (or use AppSheet Database tables) to allow independent access control and backup.
• Formulas in sheets. Avoid Google Sheets formulas in columns that AppSheet reads. AppSheet has its own expression engine and cannot evaluate Sheets formulas on the server side. Use AppSheet virtual columns or App formulas instead.

2.5 When to move beyond Sheets

Consider migrating to AppSheet Database or CloudSQL when:

• Any single table exceeds 10.000 rows
• You need transactional integrity (e.g. financial records, statutory returns)
• Multiple apps need to share the same canonical data source
• You require audit logging at the database level
• Performance becomes unacceptable due to sync times

3. Shared drive strategy and file organisation

How you organise your AppSheet apps, data sources, and supporting files in Google Drive has a direct impact on continuity, governance, and team resilience. If apps live in individual users’ personal Drives, you are one leaver away from a broken application.

3.1 Use Shared Drives, not Personal Drives

Every AppSheet application and its associated data must live on a Google Shared Drive. This Is non-negotiable for a corporate environment. Shared Drives are owned by the organisation, not the individuals, which means apps and data persist regardless of staff changes.

When an app’s files live on a Shared Drive, any member of that drive with appropriate permissions can manage the app. This eliminates single points of failure and ensures business continuity – a critical concern for local authorities where staff turnover in digital teams can be high.

3.2 Recommended Drive structure

One Shared Drive per application (or per service area with tightly coupled apps). This is the recommended approach for most local government contexts. The reasons:

• Access control granularity. Shared Drive membership controls who can see the underlying data files. If all your apps share one drive, everyone with access to any app can potentially browse any other app’s data sheets. Separate drives let you restrict access to sensitive data (e.g. safeguarding, housing, revenues and benefits) at the Drive level.
• PII containment. UK GDPR requires data minimisation. Staff working on parks booking apps should not have incidental access to adult social care data simply because both apps’ sheets sit on the same drive.
• Audit clarity. It is far easier to audit access to a Shared Drive scoped to a single app or service than to untangle permissions on a monolithic drive containing fifty apps.
• Transfer and decommissioning. When an app is retired, you archive or delete one Shared Drive. Clean.

The counter-argument, a single Shared Drive for all apps, reduces administrative overhead in small teams. If your authority has fewer than ten AppSheet apps and none process sensitive personal data, a single drive with a careful folder organisation may be pragmatic. But this approach does not scale, and it creates risk the moment PII enters the picture.

3.3 Configuring the default App folder

Every AppSheet account has a default folder path (usually /appsheet/data). For corporate environments, configure this to point to the relevant Shared Drive so that new apps and their file uploads are stored in the correct location from the outset, rather than defaulting to the creator's personal Drive.

3.4 Shared Drive membership and the principle of least privilege

• App developers/owners: Manager or Content Manager role on the Shared Drive
• App testers: Content Manager or Contributor role (depending on whether they need to modify data sheets directly)
• End users: Should NOT be members of the Shared Drive at all. Their data access is mediated entirely through the AppSheet app and its security filters. Adding end users to the Shared Drive exposes the raw data sheets, bypassing all app-level access controls.

This is a critical point. AppSheet's security model assumes that end users access data only through the app. If users can open the underlying Google Sheet directly, your security filters, role-based access, and PII protections are meaningless.

4. Security, roles, and data access

Security in AppSheet operates at multiple layers, and getting it right is especially important for local government where you are processing residents' personal data under UK GDPR obligations.

4.1 Authentication

AppSheet supports authentication via Google account sign-in (the default for Workspace environments) and can integrate with your organisation's identity provider. For local government:

• Require sign-in for all apps that access any personal or operational data. The only exception might be a truly public information-only app with no data collection.
• Restrict app access to your domain using the "Require user authentication" setting with "Only users in my domain" selected. This prevents accidental exposure to external users.
• Use Google Groups for access management rather than adding individual email addresses. Map groups to your organisational structure (e.g., housing-team@council.gov.uk, envhealth-officers@council.gov.uk).

4.2 Role-based access control

AppSheet supports role-based access through a combination of user tables and the USERROLE() function. The recommended implementation:

1. Create a Users table in your app with columns for email address, role (e.g., "Admin", "Manager", "Officer", "ReadOnly"), team/service area, and any other attributes needed for filtering.
2. Define roles that map to your organisational hierarchy and data access requirements.
3. Use USERROLE() in security filters and slice conditions to control what data each role can see and modify.
4. Use USEREMAIL() for row-level ownership where officers should only see their own cases or records.

Example security filter for a Cases table where officers see only their assigned cases, but managers see all cases in their service area:

1OR(
2  [Assigned_Officer_Email] = USEREMAIL(),
3  AND(
4    USERROLE() = "Manager",
5    [Service_Area] = LOOKUP(USEREMAIL(), "Users", "Email", "Service_Area")
6  ),
7  USERROLE() = "Admin"
8)
Copy

4.3 Performance considerations for security filters

Security filters are evaluated for every row in a table on every sync. For large datasets, poorly constructed filters cause serious performance degradation. Follow these rules:

• Keep filters simple. The most efficient filter is a direct column-to-value comparison, e.g., [Officer_Email] = USEREMAIL(). AppSheet can optimise this into a server-side query.
• Avoid nested lookups in filters. If you need to resolve a value (like team membership), pre-compute it and store it in the Users table rather than doing a LOOKUP() inside the security filter.
• Use IN() with caution. Filters that check membership in a list (e.g., IN([Ward], SELECT(Users[Wards], [Email] = USEREMAIL()))) are expensive and do not scale.
• Test with realistic data volumes. A filter that works fine on 50 rows may collapse on 5,000.

4.4 Handling PII under UK GDPR

AppSheet provides specific PII-handling features that are essential for local government compliance.

Mark columns as PII. In the AppSheet editor, you can designate individual columns as containing Personally Identifiable Information. When a column is marked as PII, AppSheet strips that data from its internal logging and audit trail entirely. This means PII values will not appear in AppSheet's server-side logs, error reports, or audit exports.

Columns that should be flagged as PII in a local government context include:

• Full names (where combined with other identifiers)
• Addresses and postcodes
• Email addresses and phone numbers
• National Insurance numbers
• Dates of birth
• NHS numbers
• Any safeguarding or social care notes
• Council tax reference numbers
• Housing tenancy references
• Photographs of residents

Data minimisation. Only collect data that is necessary for the app's purpose. AppSheet makes it easy to add columns. Resist the temptation. Every column of personal data is a liability under GDPR.

Retention and deletion. AppSheet does not have built-in data retention policies. You must implement deletion or anonymisation processes externally. Use Apps Script automations (see Section 7) to periodically purge records older than your defined retention period. Document your retention periods in your app's Data Protection Impact Assessment (DPIA).

Subject Access Requests (SARs). Design your data model so that all data relating to an individual can be identified and exported. The USEREMAIL() or a resident ID key should allow you to pull all related records across tables. Build a dedicated "SAR Export" view or action if your app handles significant volumes of personal data.

Data Protection Impact Assessments. Any AppSheet app processing personal data - particularly special category data (health, ethnicity, criminal convictions) - requires a DPIA before deployment. This is a legal requirement under UK GDPR Article 35. Your authority's DPO should be involved from the design stage.

4.5 AppSheet's platform security

AppSheet provides enterprise-grade security controls at the platform level:

• SOC 2 Type II certified - independently audited security controls
• Data encrypted in transit (TLS) and at rest
• No data stored on end-user devices beyond cached data for offline use (which syncs and clears)
• Governance policies can be applied at the team level to control which data sources can be connected, which features are available, and what level of access different teams have
• Audit logging through Google Workspace admin console

4.6 Disabling external sharing

For apps processing personal data, ensure that external sharing is disabled in the app's security settings. This prevents app creators from accidentally sharing apps with users outside your council's Google Workspace domain. This setting should be enforced at the organisational unit level through the Google Workspace admin console, not left to individual app creators.

5. Environment strategy

One of the most common mistakes with low-code platforms is treating them as if they don't need proper environment separation. "It's just a spreadsheet app" is how you end up with a broken production system because someone was testing a formula change on live data. AppSheet does not provide built-in environment management in the way that traditional web frameworks do, so you need to construct it yourself.

5.1 The Three-Environment model

Adopt a Development → Testing → Production pipeline, even if the "environments" are simply separate copies of the same app pointing at different data.

Development (DEV)

• A copy of the production app with its own copy of the data source
• All changes are made here first
• Used by the app developer/citizen developer
• Data can be messy, incomplete, or synthetic — it doesn't matter
• This is where you experiment, break things, and iterate

Testing / Staging (TEST)

• A copy of the DEV app once a set of changes are ready for review
• Points to a test data set that mirrors production structure but uses synthetic or anonymised data
• Used by a small group of trusted testers from the actual user base
• Purpose: validate that the changes work correctly for different roles, on different devices, and with realistic data volumes
• Run AppSheet's deployment check here

Production (PROD)

• The live app used by all end users
• Changes are only promoted here after passing testing
• The data source is the real, operational data
• Deployed status is set; deployment check has passed

5.2 Implement environments using App Copies

AppSheet's "Copy App" feature is the primary mechanism for creating environments:

1. Create the PROD app on its Shared Drive with its production data.
2. Copy the app (with the "Copy data" option checked) to create the DEV version. This gives you a separate app with its own data source, so changes to DEV data do not affect production.
3. When ready to test, copy DEV to create a TEST version, or simply share the DEV app with testers and use "Preview App as" to validate different user roles.
4. When ready to promote to production, use AppSheet's "Upgrade App" feature. This takes the definition (structure, views, workflows, security) from the newer version and applies it to the production app, leaving the production data source untouched.

5.3 Managing data sources across environments

The trickiest part of environment management is data. Here is the recommended approach:

• DEV and TEST should never point at production data. Copy the production sheets to create dev/test data sources, then anonymise any personal data in the copies.
• When promoting changes, use "Upgrade App" which updates the app definition without changing the data source. This is the equivalent of a code deployment that does not touch the database.
• Structural changes to data (new columns, renamed columns, new tables) must be applied to the production data source separately before or during the upgrade. Document these as migration steps.
• Never test with real PII in non-production environments. Create a synthetic data generator (an Apps Script is ideal for this - see Section 7) that produces realistic but fake resident data for testing.

5.4 The deployment checklist

Before any promotion from TEST to PROD, complete this checklist:

1. Run AppSheet's built-in deployment check - resolve all errors and review all warnings
2. Test on actual devices (mobile and desktop) used by your officers/staff
3. Test with at least one user per role to verify security filters
4. Verify that automation bots trigger correctly and do not duplicate actions
5. Confirm that file uploads (photos, signatures, documents) save to the correct Shared Drive location
6. Review the sync time - if it exceeds 10 seconds on a typical dataset, optimise before deploying
7. Confirm that PII columns are marked correctly in the new version
8. Update the change log documentation
9. Notify users of any changes to workflow or interface
10. Obtain sign-off from the app owner / service area lead

5.5 Versioning and change management

AppSheet does not have native version control (no Git, no commit history). You must compensate for this:

• Maintain a change log as a Google Doc in the app's Shared Drive. Record every change: date, author, what changed, why.
• Before major changes, take a copy of the current app as a snapshot. Name it with a date and version number (e.g., "Housing Inspections App — v2.3 — 2026-03-15").
• Use the app description field in AppSheet settings to record the current version number.
• For critical apps, consider exporting the app definition periodically and storing it in a version-controlled repository (e.g., a council GitHub or GitLab instance).

6. Automation and AppSheet bots

AppSheet's built-in automation system (bots) provides event-driven workflows without code. For local government, common use cases include sending notification emails when a case is assigned, generating PDF reports when an inspection is completed, escalating overdue tasks, and updating related records.

6.1 Bot architecture principles

• One bot per business event. Don't overload a single bot with unrelated logic. A bot that fires on "case created" should handle case creation tasks; escalation logic belongs in a separate scheduled bot.
• Reuse processes and tasks. AppSheet automation encourages reusable components. Build generic processes (e.g., "Send Notification Email") that can be called from multiple bots with different parameters. (AppSheet Help — Automation: The Essentials)
• Use scheduled bots for maintenance tasks such as sending weekly summary reports, flagging overdue cases, or triggering data retention cleanup.
• Test bots in DEV first. Bot errors in production can cause data corruption, duplicate emails, or missed notifications. Always test automation changes in a development environment.

6.2 Integrating Apps Script via the connector

The Apps Script connector for AppSheet allows bots to call Apps Script functions directly, passing data from the app as arguments. This is the bridge between AppSheet's no-code automation and more complex server-side logic.

Use cases for the connector in local government:

• Generating complex PDF documents (inspection reports, decision letters, FOI responses) using Apps Script to populate a Google Doc template and convert to PDF
• Sending data to external systems via API (e.g., updating a housing management system, posting to a case management API)
• Running data validation or deduplication logic that exceeds AppSheet's expression capabilities
• Creating calendar events or booking rooms via the Calendar API
• Managing file operations on Google Drive (moving, renaming, archiving files)

7. Apps Script as shared infrastructure

This is where you move beyond individual apps and start building a platform. In a traditional web development environment, you would have shared libraries, common services, and infrastructure code that multiple applications depend on. You can, and should, do the same with Apps Script.

7.1 The case for shared Apps Script libraries

Apps Script supports libraries - standalone script projects that can be imported and reused across multiple other scripts. This means you can build a set of common functions once, test them, version them, and share them across every AppSheet app (and every other Apps Script project) in your organisation.

Benefits for local government:

• Consistency. Every app that generates a PDF uses the same PDF generation function, producing consistent output.
• Maintainability. Fix a bug in the shared library, and every consuming app benefits immediately (or on the next version bump).
• Governance. Your IT team can audit and approve a small number of shared libraries rather than reviewing custom code in every individual app.
• Skill efficiency. Citizen developers don't need to write Apps Script. They build their app in AppSheet and call pre-built library functions through the Apps Script connector.

7.2 Recommended shared libraries

Build and maintain the following shared Apps Script libraries as organisational infrastructure:

• PDF generation library. Generate PDF documents from Google Doc templates populated with data from AppSheet.
• Backup library. Automate backups of Google Sheets data used by AppSheet applications.
• File management library. Manage files created by AppSheet (uploaded photos, signatures, generated documents).
• Deduplication library. Identify and manage duplicate records in AppSheet data sources.
• Notification and communication library. Centralise email and notification logic for consistent branding and audit trails.

7.3 Library versioning and deployment

Apps Script libraries support versioning. When you save a new version of a library, consuming scripts can choose which version to use.

Recommended versioning practice

1. Development. Work on the library in HEAD (unversioned). Test thoroughly.
2. Release. Save a new numbered version with a description of changes.
3. Consuming scripts. Pin to a specific version number, never HEAD. This prevents untested changes from propagating to production apps.
4. Upgrades. When a new version is released, update consuming scripts one at a time, testing each.
5. Documentation. Maintain JSDoc comments on all public functions. Apps Script's editor uses these for autocomplete and documentation.

7.4 Performance considerations

Apps Script libraries add latency to script startup. Each imported library must be loaded when the script initialises. For scripts called frequently (e.g., via the AppSheet connector on every form submission), this overhead matters.

Mitigations

• Keep libraries focused. Don't create one monolithic "utils" library. Split into purpose-specific libraries so scripts only load what they need.
• For latency-critical functions, consider copying the relevant code directly into the consuming script rather than importing the library. Use the library as the canonical source and copy as an optimisation.
• Avoid importing libraries inside functions called by google.script.run in HTML Service interfaces, as each call re-initialises the library.

7.5 Access control for Shared Libraries

• Store each shared library in its own Shared Drive (or a dedicated "Platform Libraries" Shared Drive).
• Only the IT/digital team should have edit access to shared libraries. AppSheet developers should have view access only.
• Use deployment IDs to share libraries. Consumer scripts reference the library by its script ID and version. They do not need edit access.
• Maintain a registry (a simple Google Sheet or Notion page) listing all shared libraries, their purpose, current version, script ID, and owner.

8. Deployment pipeline

Bringing it all together, here’s our recommendation for the end-to-end deployment pipeline for an AppSheet application.

8.1 Phase 1 - Design

Before touching AppSheet:

1. Define the problem. What manual process or spreadsheet are you replacing? Who are the users? What outcomes are you seeking? Align with TCoP Point 1: "Define user needs."
2. Complete a DPIA if the app will process personal data.
3. Design the data model on paper or in a diagramming tool. Identify tables, relationships, keys, and PII columns.
4. Define user roles and access requirements. Who can see what? Who can edit what?
5. Identify shared library dependencies. Will you need PDF generation? Backup? Notification emails? Check what already exists in your shared library registry.
6. Get sign-off from the service area lead and (if PII is involved) the DPO.

8.2 Phase 2 - Development

1. Create the Shared Drive for the app (if not using an existing service-area drive).
2. Create data sources (Google Sheets or AppSheet Database tables) with the designed schema.
3. Build the app in AppSheet, starting with data connections, then views, then actions, then automation.
4. Implement security filters and roles from the start, not as an afterthought.
5. Connect to shared Apps Script libraries for any required infrastructure functions.
6. Test as you build using the in-editor preview and "Preview App as" for different roles.

8.3 Phase 3 - Testing

1. Copy the app to create a TEST version with its own data source.
2. Populate test data using synthetic data (generated via Apps Script).
3. Recruit 3–5 testers from the actual user base, covering each defined role.
4. Testers use the app on their actual devices for at least one full week (or one full business cycle, whichever is longer).
5. Collect feedback via a simple form or shared document.
6. Fix issues in DEV, re-copy to TEST, re-test. Iterate.
7. Run the AppSheet deployment check and resolve all issues.

8.4 Phase 4 - Production

1. Apply any structural changes to the production data source (new columns, new tables).
2. Use "Upgrade App" to promote the app definition from TEST to PROD.
3. Verify production. The deploying developer should test critical flows on the live app.
4. Set the app status to "Deployed" in AppSheet.
5. Communicate to users. Send a brief note explaining what's new.
6. Monitor for the first 48 hours. Check for sync errors, bot failures, or user-reported issues.

8.5 Phase 5 - Ongoing operations

• Weekly. Review any AppSheet error logs or bot failure notifications.
• Monthly. Review app usage metrics. Are people actually using it? Are there unused features to remove?
• Quarterly. Conduct a data quality review. Run deduplication checks. Review and prune backups.
• Annually. Review the DPIA. Confirm that data retention policies are being enforced. Check Shared Drive membership against current staff list. Review security filter effectiveness.

9. Governance

AppSheet's promise is that non-technical staff can build apps. This is true, and it's powerful, but ungoverned citizen development is a data protection incident waiting to happen. The goal is to enable citizen developers while maintaining oversight.

9.1 Establishing a Centre of Excellence

Create a small AppSheet Centre of Excellence (CoE) within your digital/IT team. This group:

• Owns and maintains the shared Apps Script libraries
• Reviews and approves citizen-developed apps before they go to production
• Maintains the playbook (this document) and training materials
• Manages the AppSheet governance policies in the Workspace admin console
• Provides support and mentoring to citizen developers

9.2 Governance policies

Use AppSheet's built-in governance controls (available in Enterprise plans) to enforce:

• Allowed data sources. Restrict which data sources citizen developers can connect to (e.g., only Google Sheets on Shared Drives, not personal Drives or external databases).
• Feature restrictions. Disable features that create risk if used without IT oversight (e.g., webhook calls to external APIs, external sharing).
• Mandatory security settings. Require authentication, require domain-restricted sharing.
• App approval workflow. Require IT review before an app can be deployed.

9.3 Training and onboarding

Citizen developers should complete:

1. Google's AppSheet fundamentals training (available via Google Skills)
2. Your council's data protection essentials (existing eLearning, adapted to include AppSheet-specific guidance)
3. A local AppSheet onboarding module covering this playbook's guidance on data structure, security, environments, and shared libraries
4. Paired building. Their first app should be built alongside someone from the CoE

9.4 App registry

Maintain a central registry of all AppSheet apps in the organisation. A simple Google Sheet or AppSheet app (yes, meta) tracking:

• App name and ID
• Owner (developer) and service area
• Data sources and their locations
• Whether PII is processed (and DPIA reference)
• Current version and last update date
• Status (Development / Testing / Production / Retired)
• Shared library dependencies

This registry is essential for audit, for impact analysis when shared libraries are updated, and for decommissioning apps when owners leave the organisation.

10. Offline capability and mobile considerations

Many local government use cases involve field workers - housing inspectors, environmental health officers, planning enforcement officers, social workers - who need to use apps in locations with poor or no connectivity.

10.1 AppSheet Offline mode

AppSheet apps can work offline. When offline, the app uses locally cached data and queues changes for sync when connectivity is restored. Design considerations:

• Minimise data volume. Use security filters and slices to limit the data synced to each user's device. An inspector doesn't need every case in the borough, just their assigned cases.
• Conflict resolution. If two users modify the same record while offline, AppSheet will create a conflict on sync. Design workflows to minimise this risk (e.g., assign records to individual officers rather than allowing shared editing).
• File uploads. Photos and signatures captured offline are stored locally and uploaded on next sync. Ensure the target Shared Drive has sufficient storage.
• Test offline thoroughly. Simulate offline conditions during testing. Turn off Wi-Fi, use the app, then reconnect and verify that all changes sync correctly.

11. Performance optimisation

AppSheet performance is primarily determined by three factors: data volume, expression complexity, and sync frequency.

11.1 Key optimisation

• Use security filters to reduce data volume. A security filter that reduces a 10,000-row table to the 50 rows relevant to the current user dramatically improves sync time and responsiveness.
• Avoid volatile expressions. Functions like NOW() and HERE() in App formulas cause constant recalculation. Use them only where genuinely needed.
• Limit virtual columns. Each virtual column is computed on every sync. If you have twenty virtual columns on a large table, sync will be slow.
• Use slices to create focused subsets of data for specific views rather than loading entire tables.
• Optimise images. If your app captures photos, configure the image quality setting to an appropriate level. Full-resolution photos from modern phones are 5–10 MB each and will cripple sync times.
• Monitor sync times in the AppSheet admin dashboard. Set a target of under 5 seconds for routine sync operations.

12. Appendices

Appendix A - Glossary

Appendix B - Template DPIA Questions for AppSheet Apps

1. What is the purpose of the app and what personal data will it process?
2. What is the lawful basis for processing (most likely public task under Article 6(1)(e) for local government)?
3. Who will have access to the data, and through what roles?
4. Where is the data stored (Shared Drive location, data region)?
5. What security measures are in place (authentication, security filters, PII flagging)?
6. What is the data retention period, and how will deletion be enforced?
7. How will Subject Access Requests be fulfilled?
8. Has external sharing been disabled?
9. Has the app been tested with realistic data volumes and all user roles?
10. Who is the designated owner responsible for ongoing maintenance?