Getting Started with Google AppSheet

Published: December 16, 2025

← Back to Home

If you’ve built low-code apps with Microsoft PowerApps, AppSheet will feel familiar: both are data-first, low-code platforms that create UIs and automations on top of spreadsheet- or table-like sources. This guide focuses on a practical approach: start with your data, use the views AppSheet creates for you, then customize. I also dig into automation - events, bots, and actions - and explain why passing IDs consistently (rather than full objects) saves you headaches.

What is AppSheet - quick comparison to PowerApps

• Both platforms are low-code app builders that connect to data sources (Excel/Sheets, SQL, SharePoint/Dataverse, etc.).
• PowerApps often emphasizes canvas-driven, pixel-precise UIs and is tightly integrated with Microsoft 365/Dataverse. AppSheet is tightly integrated with Google Workspace and excels when your data is in Google Sheets or an AppSheet database.
• Both generate views and let you customize forms, lists, and detail pages, and both offer automation (Power Automate vs AppSheet Bots/Workflows).

If you know PowerApps, think of AppSheet as the same general model (data → views → logic) with different connectors and slightly different event/automation models.

Start with the data (really - start here)

AppSheet is explicitly data-first. Your app is essentially a set of tables (sheets) plus metadata about how to present and interact with them. Follow this order:

1. Prepare your data source: normalize where sensible, add explicit key columns (IDs), and ensure types (dates, enums, numbers) are consistent.
2. Connect the data in AppSheet and let it generate the default app - AppSheet will create views and forms automatically.
3. Design your column types, virtual columns, and computed values before spending time on UI polish.

AppSheet will generate rowkeys that are harder to track and less predictable when used in automations.

Example: SELECT with AND

Here’s a common AppSheet expression that selects a column from a table using an AND filter. The expression returns the OrderID values from Orders where Status is Open and Priority is High:

SELECT(
  Orders[OrderID],
  AND(
    [Status] = "Open",
    [Priority] = "High"
  )
)

And a slightly more contextual example that uses [_THISROW] to filter tasks assigned to the current row’s user and not completed:

SELECT(
  Tasks[TaskID],
  AND(
    ([AssignedTo] = [_THISROW].[UserEmail]),
    ([Completed] = FALSE)
  )
)

Use the views AppSheet creates (learn the defaults)

When you add a table, AppSheet scaffolds views: Deck, Table, Detail, Form, Map (if geodata). Spend time with the defaults:

• The auto-created list/detail/form flow is good UX out-of-the-box. Use it to understand how AppSheet expects relationships and references to be modeled.
• Check generated column order on forms - AppSheet guesses, but your data types and column descriptions influence the layout.
• Use the Preview and mobile emulator to see how the auto views behave across devices.

Accept the defaults early; they often cover 80% of the use cases and let you focus on the data and automation.

Customizing views (small, iterative changes)

• Rename views and change view types only after you understand how users will navigate.
• Use slices to create filtered subsets of data for specific views (e.g., My Tasks). Slices are lightweight and preserve the source data while letting you expose only what a view needs.
• Use formatting rules (colors, icons) to highlight states.
• When adding actions (e.g., quick-buttons), prefer small, focused actions that operate on a row and emit a state change. Actions can call other actions or trigger app navigation.

Automation: Events, Bots, and Workflows

AppSheet’s automation model centers on Bots and Processes. Bots respond to events (row added/updated, schedule, or webhook) and run processes made of tasks (e.g., change data, send email, call webhook).

• Events: an event is a trigger (row change, schedule, webhook). Configure conditions carefully - use expressions that reference columns or context to avoid noisy runs.
• Processes/Tasks: chain tasks like data changes, push notifications, email, and webhooks. Tasks can run sequentially or in parallel depending on your needs.
• Bots: encapsulate the event + process together and are easy to enable/disable during testing.

Practical tips:

• Start with a simple Bot that logs or emails on a test event. Confirm your event expression behaves as expected before adding destructive tasks.
• Use the audit history for Bots while testing - it shows inputs, outputs, and whether tasks succeeded.

Passing IDs vs Objects to events - consistency matters

You can pass full row objects or just IDs between actions and automations. Both work, but pick one convention and stick to it.

• Passing IDs (Mu recommendation):
  • Keeps payloads small and stable.
  • Avoids accidental stale data - when a downstream process needs the latest values, it can re-query the row by ID.
  • Easier to log and trace in audit history.
• Passing Objects:
  • Convenient for in-memory flows where the object is fresh and you want all fields immediately available.
  • Risky across async boundaries - if another process updates the row, the object you passed may be stale.

My rule of thumb: pass IDs for events that will start asynchronous automations, and pass objects only for immediate, synchronous UI flows. Document the convention in your app’s README so future maintainers follow the same pattern.

Debugging and testing automations

• Test Bots with minimal, controlled data first.
• Use temporary test slices and a test user account to avoid impacting production data.
• Check the Run History and error messages closely - they point to expression issues or permission problems on data sources.

Performance and data design

• Keep frequently queried lists small with slices and indexed columns (if using SQL/BigQuery).
• Use server-side queries (e.g., filter expressions that AppSheet can push to the data source) to avoid pulling large tables to the client.

Quick Getting-Started Checklist

• Add a definitive ID column to each table (GUID or meaningful key).
• Connect the data source to AppSheet and inspect auto-generated views.
• Create slices for user-specific or role-specific views.
• Build 1 Bot to test event -> process flow; keep it non-destructive at first.
• Standardize: decide whether you pass IDs or objects and document it.

Example Flow: Bot → SELECT → Action → Update

Below is a concrete flow using the sample tables (Orders, Tasks) shown earlier.

• Scenario: When an Order becomes Late with Priority = "High", a Bot finds related open Tasks for that order, and runs a table Action to mark each task as escalated.

1) Bot Event (trigger)

• Type: Row change (Orders)
• Condition (Event Filter Expression):

AND([
  [Status] = "Late",
  [Priority] = "High"
])

2) Select the Task IDs to process

Use SELECT to find Tasks for the current order that are not completed. The Bot/Process will pass these IDs to a “Run action on rows” task.

SELECT(
  Tasks[TaskID],
  AND(
    ([OrderID] = [_THISROW].[OrderID]),
    ([Completed] = FALSE)
  )
)

3) Table Action on Tasks (example)

• Action name: EscalateTask
• For a single row: set [Escalated] = TRUE, [EscalationDate] = NOW()
• Expression for the action’s effect (Change Data task):

Set the columns:
  Escalated = TRUE
  EscalationDate = NOW()

4) Process step: Run action on rows

• In the Bot’s Process, add a task: Run action: EscalateTask
• Rows to affect: the SELECT(...) expression from step 2. AppSheet will iterate rows and run EscalateTask for each returned TaskID.

Notes on passing IDs vs objects

• This flow passes TaskID values (IDs) from the SELECT into a “Run action on rows” task. Passing IDs is robust because the action will fetch the latest row when it runs, avoiding stale object problems across async Bot runs.
• If you instead pass full row objects, be careful with async timing — another process could update the row before your action runs.

Testing checklist for this flow

• Create a test slice or test order rows to avoid touching production data.
• First Bot Process step: have a non-destructive task (Send email or Log) that returns the SELECT results so you can verify the IDs before running the action.
• Use the AppSheet audit/run history to confirm the rows affected and to troubleshoot expression errors.

Closing notes

AppSheet is powerful when you work the way it was designed: treat the data as the source of truth, accept the auto-generated views, then customize minimally. Automations (Bots and Processes) let you replace many spreadsheet macros or manual workflows - but the key to maintainable automation is consistent patterns (IDs vs objects), small testable Bots, and clear data modeling.

Dream big!