Can I share a data source between pages?

Yes. Data sources in a page's list belong to that page. To share one across pages, create it in the App list (click + on the App list → Data Source), or copy an existing data source and paste it into the App list. App data sources are available on every page. 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 does deleting a data source list dependencies 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). The delete confirmation lists the dependencies it found. Deletion is not blocked — if you confirm, those references stop resolving, so remove or repoint them first.

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.

Managing Data Sources- UnifyApps

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

unify-applications-managing-data-sources-01-data-panel-data-source.png

Opening the Data Panel

Open the left sidebar: In the page builder, locate the left icon rail. Click the Database icon (a cylinder stack) to open the Data panel. The panel holds your data sources, variables and functions.
Find the right list: The panel shows two lists. App (top) holds data sources available on every page of the app. The list below is named after the current page (for example Homepage), with a page switcher, and holds data sources specific to that page.

Creating a Data Source

Open the + menu: In the Data panel, click + on the App list or the page's list and choose Data Source.
Select an app: The Select an app picker opens, with Most popular and All apps — for example Storage by UnifyApps, Analytics by UnifyApps, Callable, Custom HTTP Endpoint and your connectors. Pick the app. The data source is created and its configuration opens.
Configure it: On the App & Action tab, choose the action. If the app needs a connection, a Connection tab appears — choose the connection there. On the Input tab, fill in the action's inputs and set Run Behaviour. Use the Advanced tab for timing, caching and retries. See Data Source Types for type-specific configuration. To run JavaScript, create a Function instead — functions are a separate item in the Data panel, not a data source type.
Test the query: Click Save & Run (shown as Save for a manual data source, or Run when there are no unsaved changes) to execute the data source with the current configuration. Inspect the response in the Output tab. Verify the response shape matches your expectations — check field names, nesting, and data types before binding to blocks.
Give it a clear name: Rename the data source following the verbObject convention (see Best Practices). The data source is now available 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. A data source in the App list is shared by every page, so editing it changes it on every page — with no warning.

Warning: A data source is shared by every block that references it — on the current page, or on every page of the app for a data source in the App list. Changing the operation or response shape may break bindings in blocks that expect the previous response shape. Check which blocks bind to a widely-used data source before you edit it. To change it for one page only, copy it into that page's list and edit the copy.

Copying a Data Source

Open a data source's menu (the ⋯ button that appears when you hover over it) and select Copy. Then click the paste button on the App list or page list header, or choose Paste from a folder's menu. The copy is fully independent — changes to the copy do not affect the original, and vice versa.

Copying is useful for:

Creating a variant query with different parameters (e.g. copy fetchActiveOrders and rename the 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 inputs.

Versioning

Every edit you or a teammate saves — including edits to data sources — is captured automatically as an entry in the Versions panel. To roll back a data source to a previous state (see also App Versions):

Open Versions: Open the Versions panel from the builder's left navigation.
Find the version: Use Filter to narrow the list by Scope (App or Page), Version (All, Saved or Published) and Author. Select an entry to preview it — for a data source change, this shows the data source's earlier state.
Restore or create a new app: Restore this version brings that version back as your working draft. The live app is not affected until you publish. Create new app creates a new app from the selected version, leaving the current app unchanged.

Deleting a Data Source

Open a data source's menu and select Delete. If anything references the data source, a confirmation dialog lists those dependencies. Confirming deletes the data source anyway, and the references stop resolving. Remove or repoint the references first.

Note: Deletion is not blocked. Read the dependency list in the confirmation before you confirm, and cancel if you still need to migrate those 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".

Good name	Bad name	Why the good name is better
`fetchOrders`	`ds1`, `ordersQuery`	Immediately communicates operation (fetch) and subject (orders). No ambiguity.
`updateUserProfile`	`editUser`, `userUpdate`	Consistent verb-first ordering. Specific about what is being updated.
`deleteOrderItem`	`removeItem`, `delete`	Scoped to the specific object — distinguishes from deleting an order or a user.
`searchProducts`	`productSearch`, `getProducts2`	Verb-first, describes the operation precisely.

Use folders in the Data 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.

Keep User Input Out of the URL

This applies to Custom HTTP Endpoint data sources. Don't build the URL by joining user input into it. Keep the URL fixed and pass user values as query parameters, headers or the body, each bound to the value it needs. The request then stays readable, and a value with special characters can't change the address you call.

Correct vs incorrect

// INCORRECT — user input joined into the URL URL: /api/orders?status={{ searchInput.value }} // CORRECT — fixed URL, value passed as a query parameter URL: /api/orders Query parameters: status → {{ searchInput.value }}

Managing Data Sources