Grid App pattern gallery

Start from a pattern when the model boundary is already understood and the next question is how to compose the App. Each downloadable .grid file contains both a runnable model and a completed App surface; it is a source artifact, not a screenshot or pseudocode sketch.

Read Build Grid apps first if inputs, outputs, bindings, App Mode, or publishing are unfamiliar. Build the approval example step by step in Build your first Grid app.

These patterns have been verified against the frozen Grid 0.65.0 candidate source. Every artifact in this gallery has been compiled with Grid Core, parsed as an App document at version 2, checked against the current block catalog, and verified to have matching derived and configured binding contracts.

Download all five runnable sources and their SHA-256 manifest in the deterministic Grid 0.65.0 candidate App pattern bundle.

Choose a pattern

Pattern	Use it when	Model state seam	Requested capabilities
Approval workflow	A person selects a record, makes a guarded decision, and returns to a queue.	Read-only request rows; writable search, selection, decision, and feedback.	app.route, model.read, model.write
Records workspace	People create draft rows, search, filter, select, and inspect records.	Writable record array plus writable query, view, selection, and feedback; derived count.	model.read, model.write
Operations dashboard	People monitor calculated KPIs and slice a live operating dataset.	Formula-owned rows and KPI outputs; writable query and view state only.	model.read, model.write
Scenario planner	People change assumptions and compare formula-owned outcomes.	Writable assumptions and feedback; derived forecasts, margin, and projection rows.	model.read, model.write
Connector-backed app	A workflow must invoke a named external integration from a capability-reviewed App.	Read-only records; writable search, selection, and feedback; static connector action payloads.	connector.call, model.read, model.write

model.write does not necessarily mean that business records are editable. The operations dashboard requests it only because its search and view controls are model-bound inputs. If a deployed application must be strictly read-only, remove writable controls and confirm that its generated review no longer requests model.write.

Approval workflow

Use an approval flow for request queues, exception review, content moderation, release gates, and similar work where the selected entity must remain explicit across routes.

The existing completed example has three pages:

1. Home summarizes the queue.
2. Requests searches, selects, and routes with a row-scoped request ID.
3. Review reads the selected row, writes a decision and feedback, then routes back.

Its important seam is not the page count. Requests remains formula-owned and read-only, while SearchRequests, SelectedRequest, Decision, and Feedback are declared input bindings. The App allowlist mirrors those writes but does not create their ownership.

• Tutorial: Build your first Grid app
• Completed source: download approval-workflow.grid from the pattern bundle, or use the Completed app download on the tutorial page.

Adapt it by replacing the request row schema, keeping a stable selection key, and moving the actual approval policy into model formulas or rules. If approval must update a row rather than a separate decision cell, introduce a model-owned command seam or custom UI instead of treating a Table row as directly mutable.

Records workspace

Use this pattern for issue lists, customer records, lightweight inventories, and internal directories where search, status views, selection, and simple creation matter more than a custom routed flow.

Open crud-records.grid from the pattern bundle.

The artifact demonstrates:

• an explicitly writable Records array;
• an appendRow action that adds a draft object;
• shared RecordQuery and RecordView input state;
• a Table whose stable 1-based row position writes to SelectedRecord;
• a Detail block that reads the same source-row position;
• model-derived RecordCount and action feedback.

This is a CRUD foundation, not an implicit inline editor. In Grid 0.65.0, Table exposes rows, filtering, view, and selection; it does not expose arbitrary row update or delete slots. App Builder's append-row fields accept literals or enclosing Repeater row-scope values such as @item.id; they do not interpolate an arbitrary model symbol into a new object. Because the demonstration appends the literal ID NEW, Table and Detail deliberately select by the supported 1-based row position, so repeated drafts remain independently selectable. Replace that sample boundary with a model- or service-owned stable ID before adding update or delete commands.

For production create, update, and delete behavior, choose one explicit command boundary:

• append a fixed draft and edit through model-owned command inputs;
• run a named job that validates and mutates durable records;
• call a connector whose operation owns the mutation; or
• replace the generated renderer with custom UI while preserving the package allowlist.

Never mark a calculated record collection as input merely to make the UI convenient. Writable ownership is part of the model's public contract.

Operations dashboard

Use this pattern for fulfillment, support, service-level, warehouse, or financial operating views where calculations must be identical in the workbook and the application.

Open operations-dashboard.grid from the pattern bundle.

The model owns DailyOperations, OrdersProcessed, Backlog, ServiceLevel, and Health. The App only writes OpsSearch and OpsView, which drive Table filtering without duplicating business logic in the renderer. A KPI band, status badge, progress indicator, chart, and detail table all observe the same reactive graph. Conditional success and warning variants keep the health label and visual treatment aligned when Health changes.

Prefer a built-in dashboard or Layout surface when a single analytic canvas is enough. Choose App when the operating view needs standard controls, responsive composition, conditions, multiple pages, or a future action flow. If the source comes from a connector, bind the blocks to the model's resolved rows and let loading, empty, and error states come from that binding snapshot.

When adapting the artifact:

1. Replace DailyOperations with the real row source.
2. Recalculate KPIs in Grid formulas.
3. Change Table and Chart column keys together.
4. Preserve query/view inputs only when filter state must be observable.
5. Test empty and error source states before publishing.

Scenario planner

Use this pattern for pricing, capacity, budgets, forecasts, portfolio assumptions, and policy what-if tools. It is the clearest example of the model/UI boundary: controls write assumptions, while the model calculates every result.

Open scenario-planner.grid from the pattern bundle.

The writable seam is Scenario, BaseRevenue, GrowthRate, CostRate, and ScenarioMessage. ForecastRevenue, ForecastCost, ForecastProfit, Margin, and Projection remain formula-owned. The reset control is a Submit button with a declarative four-target batch write; it does not reimplement forecast logic.

When adapting it:

• give every assumption a safe default and an appropriate unit tag;
• enforce real validation in model formulas or rules, not only input min/max presentation;
• bind results as Metrics, Stats, Alerts, Tables, or Charts;
• test zero and boundary values, especially before dividing to calculate a rate;
• keep the reset batch limited to declared inputs.

The artifact's simple forecast is intentionally transparent and returns a zero margin when forecast revenue is zero, avoiding a valid control state becoming a divide-by-zero error. Replace its formulas with the actual domain model while retaining the same input/output ownership split.

Connector-backed app

Use this pattern only when an end-user action must cross the model boundary to a configured service, such as synchronizing CRM accounts, creating a ticket, or requesting an external refresh.

Open connector-backed-app.grid from the pattern bundle.

It provides two callConnector actions for the connector named crm:

{"operation":"sync_accounts","mode":"incremental"}

{"operation":"sync_accounts","mode":"full"}

The payload property is static JSON. Grid passes the connector name and payload through the host bridge; the host must expose the bridge and grant connector.call. The action's returned value is not automatically assigned to a model symbol. In this pattern, success or failure writes ConnectorFeedback; refreshed account rows must arrive through the model's actual connector/data workflow.

Before publishing a connector-backed App:

1. Replace the example connector name and payload with an installed operation's exact contract.
2. Keep credentials and secrets in the host or connector configuration, never in connectorPayload.
3. Decide how successful external work updates model state.
4. Test denied grants, unavailable bridges, timeouts, and connector failures.
5. Review the generated connector.call capability and every payload again.

The example compiles without network access, but its buttons only perform real external work in a running host with a configured crm connector. That distinction makes the artifact safe to inspect while keeping runtime requirements explicit.

Adapt a source artifact safely

For any pattern:

1. Download the exact .grid file and open it in a Grid 0.65.0 candidate-compatible environment.
2. Rename the model and App surface without changing !type = "app".
3. Replace the sample model state before changing the UI tree.
4. Verify every intended write target is declared input or has another explicit writable ownership contract.
5. Open the App Builder and let it normalize the document and regenerate [bindings] after edits.
6. Review required bindings, action plans, and requested capabilities.
7. Remember that Builder Preview is live: its controls and actions can write, run jobs, or call connectors. Use disposable data there, then verify the same behavior in Open as app or App Mode.
8. Publish only after the model is deployed and the capability review matches the intended boundary.

Use Assignments and ownership for the input/output contract, App block and action reference for exact Builder fields, and Workbook Surfaces for the canonical App surface specification. When standard blocks stop being enough, continue with Take an App Builder contract to React or Vue.