Connector catalog#

This is the overview of every datasource connector Reportworq can connect to. Each is added and tested the same way, in Settings > Integrations > DATASOURCES; see Connect a data source. Datasource connections are global to the instance, and each one's Availability setting decides which workspaces may use it. The tables below give the category, the authentication approach, and the traps that most often block a connection.

The connectors that need the most setup have their own detailed pages, with screenshots and the full field-by-field walkthrough. Use this catalog to find the connector you need, then follow its detailed page:

• Connect IBM Planning Analytics for TM1 and Planning Analytics (self-hosted, IBM Cloud, and IBM SaaS (MCSP) for Planning Analytics as a Service).
• Connect Oracle Smart View for Oracle EPM Cloud (Oracle Fusion Cloud EPM Planning), refreshed from a Smart View grid.
• Connect SQL Server, OLE DB, and ODBC for choosing between the native SQL Server connector and the generic OLE DB and ODBC connectors, with example connection strings for each.
• Connect SQLite for a file-backed SQLite database, on the server or inside the repository.
• Connect CData sources for the API and SaaS systems (Salesforce, Jira, NetSuite, Workday, and others) reached through a CData driver.
• Connect Snowflake for the Snowflake data warehouse, through the guided CData tile (preferred) or a native ODBC connection.
• Connect QuickBooks Online for the QuickBooks Online CData source, including how to complete the OAuth sign-in on a headless or server install.
• Connect Excel for an Excel workbook read as tables, on the server or shipped inside the repository with the repository: prefix.

This catalog covers datasource connectors only, the sources Reportworq reads data from. AI provider connections (OpenAI, Azure OpenAI, and the other model providers, with their API keys) are a separate integrations family; to configure one, see Connect an AI provider.

Reportworq also ships one datasource that reports on Reportworq itself: the Reportworq Content Store, a built-in, one-click, self-configuring connector to the instance's own jobs, run history, audit trail, users, and integrations. Because it is set up and governed from the administrative side, its guide lives with the auditing material: see Connect the Reportworq Content Store.

OLAP and planning sources#

Relational databases#

CData bridged sources#

CData builds drivers that make an API or SaaS system look like a relational database. Reportworq licenses and embeds them so that a system with no SQL surface of its own, Salesforce or HubSpot for example, can be queried with the same table-or-SQL experience as SQL Server. That is why these connectors behave like the relational ones and why their connection properties look like a database connection string.

Every CData source Reportworq ships is listed below. Each connector name links to CData's own ADO.NET documentation for that driver, which is the authoritative reference for its connection properties, supported tables, and authentication options. Reach for it whenever you need a property that is not on the Reportworq form. For the shared setup, see Connect CData sources.

Snowflake is also a CData driver, but it is listed with the relational databases above because that is where customers look for it.

Connect a Workday Adaptive sandbox or non-US environment#

By default the Workday Adaptive Planning connector reaches the US production environment, and you can leave the two environment fields blank. To connect a sandbox, a preview environment, or a non-US region, set them on the connection:

• API URL - the base API host for the environment. Leave it blank for US production. Set it to the environment's host to reach a sandbox, a preview environment, or a non-US region. The API URL field has an examples menu (Production, Sandbox, and Preview for the US) so you do not have to type the host by hand. Enter only the host, for example https://api.sbox.adaptiveplanning.com; Reportworq adds the API path and version itself, and the version stays managed by the product.
• Instance Code - the Adaptive instance to use within that environment. Leave it blank to use the default instance. Set it to select a specific instance.

A sandbox is a different host, not a checkbox: each Workday Adaptive environment has its own hostname, and every region has its own production, sandbox, and preview hosts.

US environment hosts#

The older host api.adaptiveinsights.com is a DNS alias for US production api.adaptiveplanning.com; both reach the same endpoint. Each non-US region (Singapore, Japan, India, EU, and Australia) has its own hostname, with a .sbox. sandbox variant. For the full, authoritative list of hosts, see Workday: Authentication URLs and IP addresses.

Allowlisting for IT#

The connection is outbound from the Reportworq server to the Adaptive host on port 443. If your network restricts outbound traffic, allowlist the Adaptive host by hostname. Workday runs Adaptive on AWS and its published IP ranges rotate, so a hostname allowlist is the durable choice. If your firewall must allowlist by IP address instead, get the current per-cluster ranges from the Workday Authentication URLs and IP addresses page or from Workday support, and plan to refresh them, because they change.

Reportworq uses the host as you enter it; it does not check that the host is a valid Adaptive environment. Test the connection after saving to confirm the environment is reachable.

Per-connector traps#

• Oracle Smart View is EPM Cloud, not a relational database. The Oracle Smart View connector refreshes a Smart View grid and re-queries the Oracle EPM Cloud REST API with Basic auth. It has no table or SQL surface. To reach a relational Oracle database, use ODBC, OLE DB, or a CData driver instead. See Connect Oracle Smart View.
• Salesforce needs a Security Token. Basic auth alone is not enough. Reset the security token in Salesforce; it is emailed to you and appended to the password. The connection fails without it.
• Pigment API-Export URLs are hard-validated. An API-export model supplies a URL and payload, and the URL must begin with https://pigment.app/api. Any other URL is rejected at save with an error.
• Pigment block imports. Block imports cover four block types (Metric, Dimension List, Transaction List, Table), each needing its own data connection after import.
• Re-importing creates a duplicate, not an update. Re-importing an already-imported Pigment block, or re-selecting an already-imported relational table, creates an additional copy rather than updating the existing one. Edit the existing item in place to avoid silent model bloat.
• Adomd (Power BI / SSAS) has three separate connection traps. First, MFA-required accounts cannot use password mode; switch to a service principal. Second, an MDX query must return a flat, tabular result or it errors; use the MDX query type's crosstab render mode for matrix output. Third, XMLA is only exposed on Power BI Premium, PPU, or Fabric workspaces (not shared or Pro), with the XMLA endpoint set to Read or Read/Write, and for service principals the tenant-admin setting "Allow service principals to use Power BI APIs."
• Workday Adaptive metadata is cached. The dimensional-structure cache defaults to 24h freshness. If a source's structure changed, use Refresh Metadata before a run; save changes first.
• "Workday" and "Workday Adaptive Planning" are two different connectors. Workday Adaptive Planning is the planning product and is reached through the Adaptive Planning API. The Workday connector reaches Workday itself - Financial Management and HCM. Adding the wrong one is the most common mistake here, and its Workday-tenant sign-in makes the Adaptive connector look like it covers Workday when it does not.
• What a Workday connection can see is set by the Workday user, not by Reportworq. The connector exposes only the data sources the authenticating Workday user is entitled to. An integration user holding HR security alone returns HR data and no financial data, which looks exactly like a connector that "only does HR". If financial data is missing, widen the integration user's security in Workday rather than changing anything in Reportworq.
• Pick the Workday Connection Type to match the job. Reports is the usual choice for financial reporting: build a custom report in Workday, expose it as a web service, and point Custom Report URL at it. WQL suits live querying of Workday data sources. REST and SOAP are lower-level; SOAP additionally needs Service, WSDL Source, and WSDL Version, and is the fiddliest of the four.

Notes and limits#

• Only administrators can add or configure datasource connectors.
• Datasource names must be unique, and editing, disabling, or deleting a live datasource breaks every job and form that refreshes from it. See Connect a data source.
• Writeback (data collection) paths, where available, are gated on a writeback license.

Going deeper. To turn any of these connectors into curated, reusable data for report authors, see Data models.