Build a data model from a workspace file#

A data model does not have to bind to a connection in Settings > Integrations. When the file it needs to read - an Excel workbook or a SQLite database - already lives in the same workspace as the model, point the model straight at that file. No connection is added to Integrations, so dropping many workbooks or databases into a workspace folder never clutters the datasource list.

This is the recommended way to model a workbook or database that belongs to one workspace and one purpose. If instead the file should be shared as a connection other workspaces or other models can also use, see Connect Excel and Connect SQLite for Configure as data source, the admin path that creates a real Integrations connection from the same file.

Before you begin#

• The file is an Excel workbook (.xlsx, .xlsm) or a SQLite database (.db, .sqlite, .sqlite3), uploaded into the same workspace where you are building the data model.
• SQLite databases must be an allowed upload type in this workspace. On an existing install, an administrator may need to add the Databases file-type category to the workspace's upload allow-list first - see Notes and limits.
• You have permission to create a data model in the workspace (the same permission New > Data model requires).
• The workbook or database follows the same layout rules as any Excel or SQLite source: a header row of column names for a worksheet table, or ordinary tables in the database. See Connect Excel and Connect SQLite for the query modes and what each driver exposes.

Two ways to start#

From the file, in the workspace browser#

1. In the workspace's file tree, find the Excel workbook or SQLite database.
2. Open its ⋮ (more actions) menu and choose Create data model.
3. Reportworq creates a data model in the same folder, named after the file, already bound to it, and opens it in the editor.

From an existing data model's Source tab#

1. Open the data model (new or existing), select Source in the rail, then the Connection section.
2. Under Source, choose Workspace file instead of Connection.
3. Select Browse… and pick an Excel workbook or SQLite database from this workspace's files. The picker lists only files you can see, filtered to Excel and SQLite.

Either way, the model's Source screen now shows the picked file's path instead of a connection name, and every view built from here reads that file.

Build the views#

Once the file is picked, the rest of the data model editor works exactly as it does for a connection in Integrations:

• Table or View lists the workbook's worksheets (and named ranges), or the database's tables.

• SQL Query works the same way it does against any relational source, for example:

  SELECT Region, Product, Sales FROM Sales
  

• Import Fields, Preview, filters, and variables all behave as documented in Data models.

Portability#

The data model stores the file's path inside its own workspace - never a workspace id. That is what makes the model portable: when you export the workspace and import it elsewhere, the model resolves the same path in the new workspace and keeps working, with nothing to reconfigure.

The trade-off is the same one any relative path carries: if the file is later renamed or moved to a different folder, the model's reference breaks. Reopen the model's Source tab and Browse… to the file's new location to repoint it.

How your data stays secure#

• No datasource connection is created or stored for a workspace-file model. The connection is built in memory each time the model is used - previewed, imported, run in a job, or bound to a report - and discarded afterward.
• The file never leaves the workspace's own access rules, and that is checked every time, not just when you pick it. You can only pick, save, or preview a file you can already see through the workspace's content permissions. If your folder access changes later so that you can no longer see the file, Reportworq refuses to preview it or save the model's Source tab pointed at it - it does not silently keep working on your old access. The model itself can also only ever read files in its own workspace - never another workspace's file, even if you know its path.
• Scheduled jobs and campaigns are not affected by an author's own access changing. A distribution job or contribution campaign that runs on a schedule, or through the background job runner, reads the file the same way a report source file does - it is not limited by any one person's folder permissions, so it keeps running even if the author who built the model later loses visibility into the file.
• The connection is always read-only. Reportworq opens the file for reading only, whichever driver is used underneath. A write-back operation against it, such as a SQL export or RWSQLUPDATE targeting the file, fails instead of silently doing nothing. To change the data, edit the file itself and upload the new version into the workspace.
• The server keeps a private, working copy of the file for the drivers to read from. That copy refreshes automatically the next time the model is used after you upload a new version of the file, and it is removed when the file or the workspace is deleted.

If the source breaks, or you don't have access to the file#

The editor never fails to open just because its file source is broken. If the file was renamed, moved, deleted, or you no longer have permission to see it, the model's Source tab shows a warning explaining why, and the rest of the editor still opens normally (using the standard connection editor as a stand-in). Select Browse… to pick the file again - either the same file at its new location, or a replacement.

What happens on import#

When you import a workspace (or a data model) that was exported from elsewhere:

• If the model's source file is not visible to you in the target workspace - for example, it sits in a folder you don't have access to - the model imports without a source. A warning is recorded; open the model's Source tab and Browse… to pick a file.
• If the source file simply hasn't been uploaded yet, the model keeps its source pointer and starts working as soon as you upload the file to the same path.
• Either way, the imported model is treated like a fresh copy: it gets its own new internal identifier, so it never accidentally shares its source connection with the model it was exported from.

Notes and limits#

• SQLite uploads may need an admin step first. A fresh Reportworq install permits .db / .sqlite / .sqlite3 uploads out of the box. An install upgraded from an earlier version keeps its existing upload allow-list, so a .db upload may be refused with "These file types are not permitted…" until an administrator adds the Databases category. That setting lives in Settings > Security > Workspaces > the workspace > Workspace Files, under Allowed File Types - use the + Databases quick-add chip.
• Preview needs a saved model, under one specific setting. If Settings > Performance is configured to run reporting queries out of a separate process, previewing a file you just picked but have not yet saved will not find it - the out-of-process worker only sees a model's saved source. Save the model once after picking the file, then preview.
• Excel workbook and SQLite rules otherwise match the connector pages: see Connect Excel and Connect SQLite for worksheet/table layout, query modes, and driver behavior.

Related pages#

• Data models for curating fields, filters, variables, and publishing a view once the source is bound.
• Connect Excel and Connect SQLite for the same files used as a shared Integrations connection instead (Configure as data source), and for the query modes both paths share.
• Connect a data source for the general Integrations add-and-test flow.