Managing Data Sources

The Data Sources panel is where you create, inspect, edit, clone, and delete all the data connections that power your app's blocks. This page covers every management action available from the panel, version control of data sources, and best practices for naming and organizing them.

Opening the Data Sources Panel

1. Open the left sidebar: In the page builder, locate the left icon rail. Click the Database icon (a cylinder stack) to open the Data Sources panel. The panel lists every data source defined for the current page, grouped by type.

2. Switch scope if needed: The panel defaults to showing the current page's data sources. Use the scope dropdown at the top to switch to App-level data sources — those shared across all pages — if your app uses them.

Creating a Data Source

1. Click + New Data Source: Press the + New Data Source button at the top of the panel. A type picker appears.

2. Choose the type: Select one of the available types: REST API, GraphQL, Entity (platform object query or mutation), or JS Function (a custom JavaScript function that returns data). The type determines which configuration fields are shown.

3. Configure the connection: Fill in the type-specific fields: URL and method (REST), query string (GraphQL), object and action (Entity), or function body (JS Function). Set headers, authentication, input parameters, and any response transforms. See Data Source Types for type-specific configuration.

4. Test the query: Click Run (or press Ctrl/Cmd+Enter) to execute the data source with the current configuration. Inspect the response in the Output panel. Verify the response shape matches your expectations — check field names, nesting, and data types before binding to blocks.

5. Give it a name and save: Set a descriptive name following the verbObject convention (see Best Practices). Click Save. The data source is now available on this page and appears in all binding expression pickers and the State Explorer.

Editing a Data Source

Click any data source in the panel list to open its configuration. All fields are editable. Changes take effect immediately when saved — the data source re-runs on the next trigger. Because any block bound to this data source uses the same configuration, edits affect every block referencing it.

Warning: A data source is shared across all blocks on the page that reference it. Changing the URL, method, or response shape may break bindings in blocks that expect the previous response shape. Before editing a widely-used data source, check the Reference panel (right-click the data source → References) to see which blocks depend on it.

Cloning a Data Source

Right-click a data source in the panel and select Clone. A duplicate is created with the suffix _copy appended to the name. The clone is fully independent — changes to the clone do not affect the original, and vice versa.

Cloning is useful for:

• Creating a variant query with different parameters (e.g. fetchActiveOrders_copy → fetchArchivedOrders).

• Duplicating a working configuration as a starting point for a related but different operation.

• Preserving the original while experimenting with a response transform or new input parameters.

Versioning

Data sources are versioned as part of the app version — they are saved with the app whenever you publish or create a version checkpoint. There is no per-data-source version history. To roll back a data source to a previous state:

1. Open App Versions: Go to the app's Settings panel → Versions, or use the Versions button in the top bar of the builder.

2. Select the version to restore: Browse the version history. Each entry shows its creation timestamp and the author. Click a version to preview it.

3. Restore or fork the version: Restore — makes the selected version the current working version (destructive to any changes made after that version). Fork — creates a copy of the selected version as a new app, preserving the current app unchanged.

Deleting a Data Source

Right-click a data source and select Delete. If any block on the page currently references the data source, deletion is blocked — a dialog appears listing the blocks that still reference it. You must either remove the references from those blocks or delete the blocks first before the data source can be deleted.

Note: Right-click a data source and select References to see a list of every block and property that currently references it. Use this before deleting to assess impact, or when you want to migrate references to a different data source.

Best Practices

Name Data Sources Descriptively

Use the verbObject naming convention — a verb that describes the operation, followed by the object it operates on. Names should be readable as English sentences: "this data source fetches orders", "this data source creates a user".

Group Related Data Sources

Use the Data Sources panel's folder feature (right-click the panel → New Folder) to group related data sources — for example, all data sources that interact with the Orders API in an "Orders" folder. This makes navigation faster as the number of sources grows.

Use Parameterised Queries

Never concatenate user input directly into a URL or query string. Always use input parameters — defined in the data source's Inputs section — and reference them via their binding path. Parameterised inputs are sanitised by the platform before inclusion in the request.

Correct vs incorrect parameterisation

// INCORRECT — string concatenation, vulnerable to injection URL: /api/orders?status={{ searchInput.value }} // CORRECT — use an input parameter // Define input: status (type: string) // URL: /api/orders // Query param: status → {{ inputs.status }} // Bind the input in the data source Inputs panel: // inputs.status = {{ searchInput.value }}

Frequently Asked Questions

Can I share a data source between pages?

Data sources are page-scoped by default. To share a data source across pages, promote it to an App-level data source by right-clicking it and selecting "Move to App Level". App-level data sources are available on every page and are managed in the app's global Data Sources panel. Note that app-level sources do not automatically have access to page-specific state (block values, page variables) — they can only reference app-level variables and fixed values.

Why is my data source blocked from deletion even though no blocks seem to reference it?

A data source may be referenced not just in block data bindings but also in action chains (a Trigger Data Source action that points to it), page variable initial values (a variable whose default value is computed from the source), or another data source's inputs (a data source that uses another source's output as an input parameter). Use the References panel to find all references — it covers all these locations, not just block data bindings.

What is the difference between saving a data source and publishing the app?

Saving a data source writes it to your current working draft of the app — it is immediately available in the builder and preview, but is not yet visible to end users of the published app. Publishing the app creates a new published version that end users access. Think of saving as committing to draft, and publishing as deploying. Always test your data source in preview before publishing.