Plan your integrations#

This guide is for the person deciding what Reportworq should connect to and on what terms. That is a different job from getting the server installed, licensed, secured and backed up, which is the Administrator Guide.

The split is deliberate, because the two jobs are usually done by two different people at two different times:

If you are reading this and the server does not exist yet, start in the Administrator Guide and come back.

The five decisions#

Almost every Reportworq implementation comes down to the same five decisions, in roughly this order.

1. Where do report source files live#

Reportworq will not render a workbook from an arbitrary path. Source files come from a configured report provider, and that list is a security boundary as much as a convenience. Deciding this early matters because it determines who can put a file somewhere Reportworq will read it.

See Source report providers.

2. What data are we actually connecting to#

The connector list is long, and the honest answer is usually shorter than the wish list. Work out which systems are in scope for the first phase, which of them you have credentials and network access for, and which ones need a service account provisioned by someone else.

Two things to settle per source: who owns the credential, and whether the connection is workspace-scoped or instance-wide.

See Connect a data source and the Connector catalog.

3. How do people sign in#

One authentication provider is active at a time. Switching later is not a free action: existing accounts stay bound to the previous provider and have to be re-established under the new one. Decide before you onboard users, not after.

See Authentication providers.

4. Are we turning on AI, and under whose terms#

AI in Reportworq is opt-in and provider-agnostic. The decisions are which provider, whose subscription and data-handling terms apply, and which surfaces are enabled. The prompts themselves are editable and auditable, which matters if you have a review process.

See AI overview and Connect an AI provider.

5. Are we exposing Reportworq to AI clients, and how do we keep content safe#

This is the decision that most often needs a written answer before anyone will sign off. Enabling the MCP server means an AI client can reach report content. The controls exist, but you have to choose them deliberately.

See Secure content before you expose it to AI.

Two more that come up later#

Automation. Once jobs are running on a schedule, something upstream usually wants to trigger them instead, a Turbo Integrator process, a Workato recipe, a nightly ETL. That is the REST API. See REST API overview.

Extensibility. When the requirement is "the output must also do X before it is sent", that is the Script Runner. Scripts run on the Reportworq server, so decide who should be able to add one.

What good looks like#

An implementation is in reasonable shape when you can answer these without checking:

• Every report source file comes from a provider on a list you approved.
• Every data connection has a named owner and a credential that is not a person's personal account.
• The authentication cutover plan includes how you get back in if it fails.
• If AI is on, someone has read the prompts that are being sent.
• If MCP is on, someone has decided what a reader is allowed to see through it, and tested it as a reader.

Related pages#

• The integrations hub, the single screen where every connection is registered and tested.
• Administrator Guide: system requirements for the environment side.
• Accounts, groups and entitlements for who can do what once they are in.