Source report providers#

A report provider is a configured location that supplies the source files a report renders: Excel workbooks and PowerPoint templates. When an author adds a source on the Reports step, Reportworq opens the Select a Report dialog, which browses a report provider as a folder tree with a file grid.

Providers are managed in Settings, Integrations, in the Report Providers family. See The integrations hub for the add, test, enable and delete mechanics that apply to every integration family. Workspace files is the one exception - it's not a card here at all. It's a built-in provider configured per workspace on Settings ▸ Security ▸ Workspaces; see Store files in the workspace.

Report providers are global to the instance, only a system administrator configures them. Each provider's editor opens with the common integration chrome, an Enable Integration checkbox, a Display name, and an Availability workspaces dropdown that decides which workspaces may read from it, above the provider-specific settings.

They are a security boundary, not a convenience#

This is the point that gets missed. Reportworq permits report content only from trusted locations defined as report providers. A job cannot be pointed at an arbitrary server path, so it cannot be based on an invalid source or aimed at a sensitive file outside the approved locations.

That makes "which locations do we register" an access-control decision, not a shortcut. Anyone who can write a file into a registered provider can get that file rendered by Reportworq. Scope provider roots as tightly as the reports actually need.

You may define an unlimited number of providers.

Provider types#

Read-only providers are browse-and-load only. The Select a Report dialog still shows its upload, rename, delete and create-folder buttons for them, but leaves them grayed out, because the provider reports that it does not support those operations. This is why the dialog looks different depending on which provider you are in; it is not an inconsistency.

Planning Analytics folders are named after your connections. Under the Planning Analytics provider, each connection appears as a top-level folder labeled with the friendly name you gave the connection, not the raw TM1 server name. If a connection has no friendly name, the server name is shown; if two connections share a friendly name, each is shown as Name (ServerName). Saved report paths keep working, because they continue to use the server name internally.

Vena sits between fully writable and read-only. It holds no credentials of its own - its tree roots are your enabled Vena data source connections - and it supports Upload and New Folder, but only inside a process's Files Library; rename, move and delete are not supported and are done in Vena itself. Reportworq can't replace an existing Vena file, so it doesn't offer the usual Overwrite prompt for Vena: a file whose name already exists is reported as not uploaded - rename or remove it in Vena first - and every non-clashing file in the same upload still goes through. Enabling this provider is a permission decision, not just a convenience - see Use Vena as a report source for the full setup, the exact messages, and who can reach what through it.

Google Drive has its own detailed setup page. It supports two authentication models: OAuth (recommended, see Google Workspace OAuth setup) or a service account with a JSON key, Shared Drive vs. folder IDs, and optional Domain-Wide Delegation. See Set up Google Drive, which covers both models and both the provider and the matching distributor.

Do not confuse a read-only report provider with the matching distributor. Reading source files from Box or Google Drive is read-only. Delivering output to them is a separate distributor, and those do write. The same is true for the other locations that appear in both lists.

Prerequisite: at least one provider must exist#

Add a Report requires a configured report provider. On a fresh install with none registered, the action reports "No report providers are configured" and authoring cannot begin. Provider setup is a genuine prerequisite of the first report, so put it early in your implementation plan.

Working with a provider#

Authors do not configure providers, they consume them:

1. On the Reports step, select Add a Report.
2. Navigate the provider tree on the left and pick a file from the file grid.
3. Confirm with OK.

Both Excel workbooks and PowerPoint templates appear in the provider, so either can be added as report source content.

On a writable provider, Upload File(s) brings a local file into the provider so it can be added as a source. On a read-only provider the file has to arrive by that system's own means, for example someone putting it in the Box folder.

Dynamic, parameter-driven source paths#

A source file's path can embed parameter values, resolved beneath the provider root at run time. For example:

c:\temp\%param:BU% Business Unit.xlsx
Templates/%param:Region%/report.xlsx

One job then reads a different workbook per parameter combination, which is how a burst can render genuinely different templates per business unit rather than the same template with different filters.

A report using this shows a lightning-bolt icon in the Reports grid, with the tooltip "This report uses a dynamic report path." That icon is your signal that the source file is not fixed.

The resolved path is still confined beneath the provider root, so the security boundary holds.

Two operational traps#

Disabling a provider breaks viewing and running. A disabled provider can no longer resolve its sources, so authors cannot browse its files and any job referencing a file from it fails to run. Disabling is not a soft action; treat it as a change with job-level impact.

Changing a provider's folder location may strand existing jobs. Jobs hold a reference to the file as it was resolved. If you move the root, expect to update the jobs that referenced the old path.

A note on "Reportworq Drive"#

If you are coming from version 5, "Reportworq Drive" split into two distinct things in version 6:

• A built-in provider backed by the repository. It is retired: you can no longer create a new one, but existing instances stay resolvable so older jobs keep working. Disabling one does not delete its files, it only stops listing it.
• Workspace file storage, which is the replacement and is the provider you should use for new work. It is a thin layer over workspace file items, so the dialog shows the same folders, names and permissions as the workspace file browser, and uploads honor the configured file-extension allow-list.

Do not treat the two as interchangeable when planning a migration.

Related pages#

• The integrations hub for registering, testing and enabling connections.
• Plan your integrations for where this decision sits in the sequence.
• Destinations for the write side, which is a separate list.
• Script Runner, whose .csx files are also loaded through a report provider and inherit its access control.