Can included AppSheet replace one Airtable request tracker?

Included AppSheet is worth testing for one simple internal request tracker, provided the actual users and maintainers are entitled, the access tests pass and an Airtable charge can really end. A working form alone proves none of those conditions.

Consider equipment or service requests stored in Google Sheets: named employees submit and correct their own requests, one handler manages their status, and one internal email tells the requester when the status becomes Complete. Exclude external portals, sensitive HR or financial approvals, complex linked records, elaborate attachments and multiple integrations.

This is an UNEXECUTED pilot proposal. Google documentation was checked on October 21, 2026; no app was built or deployed, no tenant was inspected and no catalog prices were freshly verified.

Establish whose entitlement covers the app

Google includes AppSheet Core for each domain-verified user in eligible Workspace editions. The required app-user license depends on the creator's license: Core creators require Core or User Pass; Enterprise Plus creators require Enterprise Plus or User Pass. Included Core therefore does not cover every AppSheet app. Google's subscription rules.

Have the administrator record the actual Workspace edition, domain verification, creator account and creator tier. Check every employee, the handler and backup maintainer individually. Confirm that AppSheet is enabled for them and that the proposed app fits their entitlement; do not infer this from access to Gmail. External and unauthenticated users also require licensing, which is another reason to keep this decision internal. External-user licensing.

Check authoring separately. AppSheet distinguishes permission to use an app from permission to edit its definition, and warns that app editors may access Drive files. Require the creator and backup to demonstrate authorized editing under their actual licenses; a successful app login is insufficient. Sharing and editor access. Organization or team administration separately requires Enterprise Plus; do not assume included Core supplies those facilities for a backup. Subscription distinctions. Defer if the required maintenance arrangement needs an unconfirmed purchase.

Record applicable administrator restrictions before designing around them. Core security settings can restrict external sharing, data connections and outgoing email; other policies can constrain recipients. Keep the pilot within approved policy. Administrator feature controls.

Separate app access from source access

Use sign-in and a named allow list. Define the intended rule before configuring anything: employees can see only their own requests and correct permitted details; the handler can see the queue and change status; employees cannot change requester identity, stable request IDs or handler-only fields.

Core supports security filters that decide which rows enter the app, but Google explicitly says they are not a complete security solution and sensitive operations need source-level protection. Security-filter boundaries. Slices select subsets of rows, columns and actions for views. Our pilot requirement is to use actual security filters and test access independently; a slice showing fewer rows is not equivalent evidence of protection. Slice behavior.

Inspect the table's access mode. In as app creator mode, users can use the app without direct spreadsheet access. In as app user mode, everyone needs direct access to the source spreadsheet and folder. A private-looking app must not be undermined by broader Sheet access. Record every source grant and reject any arrangement that exposes another employee's records. For this pilot, if app-user mode would expose other employees' requests through direct Sheet access, test app-creator mode without employee Sheet or folder grants. Keep Airtable unless the resulting arrangement passes the access tests. Access modes.

Inventory every route that writes a request

List app edits, direct Sheet editors, Forms, imports, Apps Script, API clients, other apps and automated writers, including maintenance jobs. Record who owns each route, which fields it changes and how its outcome is reconciled. The proposed pilot accepts ordinary writes through this one app; any essential additional route needs separate proof.

AppSheet bots can respond to qualifying changes through their app after synchronization. Direct source changes do not automatically trigger them, and changes through another AppSheet app do not trigger this app's bots even when both share a table. Bot event boundaries.

Google offers separately configured Sheets external events for user changes, but these exclude programmatic writes such as Apps Script. Do not treat that mechanism as universal coverage or add it silently to this pilot. Sheets external events.

Run a later authorized pilot with dummy requests

Use two employee accounts, the handler and backup, plus an internal account outside the allow list. Start with distinguishable dummy requests and stable, unique IDs that remain unchanged through corrections and reconciliation. Save a baseline copy and expected outcomes before testing. Use individual sessions, not the creator's preview impersonating everyone.

Exercise	Required evidence
Each employee creates and corrects a request	Correct requester and persistent ID; permitted detail changes survive reopening and synchronization.
Each employee tries to find the other's request through search and a copied record link	No unauthorized record disclosure or edit; direct Sheet access also respects the intended boundary.
Try prohibited edits and an unlisted account	Requester identity, ID and handler-only status remain protected; the unlisted account cannot use the app. Hidden controls alone do not establish protection.
Handler processes both requests	Both appear in the authorized queue; changing one leaves the other unchanged.
Change one status to Complete	One intended internal test recipient receives the correct request ID and status, without unrelated request details.
Save an unchanged status, repeat an edit and correct unrelated text	No extra completion email; compare observed messages with the written expectation.
Exercise each inventoried source-write route on dummy data	Actual trigger behavior is recorded. Unsupported routes are excluded from operation or the pilot fails.
Investigate a deliberately disabled pilot notification	Handler detects the missing handoff; backup locates the request and explains the failure before any controlled resend.

AppSheet test mode sends emails only to the creator. A later authorized delivery trial must meet Google's deployment requirements and use the intended recipient's inbox; preview and recipient logs alone cannot prove delivery. Google also documents comparing status before and after an update. Email testing and status changes. This article performs neither deployment nor delivery testing.

For failures, record account, ID, time, app version, source-write route and expected result. Inspect synchronization, event conditions, automation execution and recipient restrictions. The automation monitor distinguishes successful, pending and failed executions. Bot monitoring. Reconcile the row and inbox before retrying; a repaired demonstration does not erase the original failure.

Prove continuity, then calculate the remaining bill

Have the backup edit and restore a harmless pilot setting using their own account, inspect the source and investigate the missed notification. Record app ownership, Sheet ownership, connection access and the planned handoff. Google's transfer process requires recipient edit access and access to the underlying files; app ownership alone does not provide those files. Rehearse an authorized pilot handoff and rerun entitlement, access and notification checks before relying on it. App transfer requirements.

Before any live cutover, test an authorized export and import of existing and closed Airtable requests into the candidate Sheet. Inventory required requester identities, timestamps, statuses, stable IDs, comments and history; do not assume the export preserves them. Compare record counts and sampled records against Airtable, and retain Airtable if any required field or history cannot be carried over.

If proceeding later, choose one system to accept new requests at cutover. Reconcile IDs, requesters, details and statuses against the baseline and transition log. On failure, stop new pilot writes, preserve both datasets, reconcile changes into the retained tracker and verify outstanding requests before reopening it. Retain Airtable until recovery is proven.

Compare actual current and proposed bills over the same term and currency, including remaining Airtable obligations and incremental AppSheet, Workspace, storage or support charges. Put unchanged Workspace costs on both sides; count each removable charge once. Track setup hours and recurring maintenance separately. Confirm the effective reduction date and eventual invoice rather than assuming a refund.

Keeping Airtable as the data source does not eliminate its subscription. Moving one tracker also leaves every other Airtable dependency to resolve. Use the Airtable inventory, retained Google Workspace record and subscription audit to record the remaining jobs. Keep the existing tracker when entitlement, access, data fidelity, notification, backup recovery or the actual bill remains unproven.