New Upload weather data from web services into TM1/Planning Analytics — Read the post →

PowerConnect FAQ (Evaluation & POC)

Common questions about PowerConnect — what it does, how it handles security and performance, how it is licensed, and where it fits relative to other tools. Each answer links to the relevant page for more detail.

Data Access & Architecture

Does the connector support genuine live access to TM1 (interactivity, writeback not required), or is it primarily a data extraction approach?

It is primarily a data extraction / refresh approach, not live interactive querying. The connector pulls TM1 cube data, metadata, and security into a Power BI dataset; it does not hold an open interactive session against TM1. Refreshes are explicit — ad-hoc (triggered in Power BI) or scheduled. There is no writeback; the flow is strictly one-way (TM1 → Power BI). See 💎 PowerConnect Fundamentals.

What architecture do you recommend for production setups (DirectQuery vs. Import vs. Hybrid)?

An Import-style model: data lands inside the Power BI dataset, you build a star schema, apply Power BI Row Level Security (RLS), then refresh — ad-hoc or scheduled. See 🔌 Loading Data and Metadata into Power BI and Star Schema.

What role do gateways or middleware components play?

There are two core components. The PowerConnect App Server (Windows or Linux, on a separate server) connects to TM1 via the REST API and performs retrieval. The PowerConnect Connector (a custom .mez connector) installs on each user's machine and is what Power BI Desktop talks to. For refresh from the Power BI Service you additionally need the Microsoft On-premises Data Gateway, which bridges the cloud Service to the App Server. Desktop path: Connector → App Server → TM1. Service path: Gateway + Connector → App Server → TM1. See Architecture.

Security & Governance

Is TM1 security (including cell-level security) fully respected?

In Power BI Desktop with OAuth2, the user logs in with their own credentials and PowerConnect uses impersonation — it connects with an admin account, then enforces that individual user's TM1 security. In the Power BI Service, the user logs in with their Power BI account (usually their email address). That email address needs to be associated with an attribute of the TM1 }Clients dimension. Once the attribute is set up, when the Power BI user opens the report the email address gets associated to the TM1 user and the RLS is applied. See Security and Configuring Row Level Security (RLS).

How is authentication handled (SSO / service accounts)?

Two modes:

  • Anonymous / Non-secured — a TM1 admin credential in the Admin portal; everyone building in Desktop sees all data (not recommended for production, fine for trial/POC).

  • OAuth2 to Microsoft (Entra / Azure AD) for production, which adds the organisational-identity check plus per-user TM1 filtering. SSO is supported on the TM1 side via CAM with SSO. For Service refresh, a service account that is both a Power BI admin and a TM1 admin is recommended. See Setting the TM1 credentials and How to configure the Gateway connection in PBI Service.

Are there any limitations regarding auditability or logging?

When data is in Power BI, a Power BI user consuming via the Power BI Service does not need a TM1 license. Only the users building dashboards in Power BI Desktop need a TM1 license. Admins can also download logs from the Admin portal (Support & Docs tab), and there is an MDX validation tool. See The PowerConnect Admin Portal.

Performance & Scalability

What are your experiences with large cubes / complex models?

Memory in the App Server scales with three factors: roughly ~320 bytes per row, ~97 MB per numeric measure column at 0.5M rows, and ~9 MB per 10 extra characters of string data at 0.5M rows. Rows are usually dominant and scaling is approximately linear. For very large result sets (multi-million rows × multiple measures), distribute queries across multiple PowerConnect Service instances or limit view scope. Baseline server spec: 8 cores / 16 GB / 20 GB disk. See PowerConnect Sizing Guide.

How does the connector behave under high user concurrency?

There are two scenarios:

  • Users on the Power BI Service won't impact PowerConnect, since the data is refreshed by admins or via scheduled refresh — the Power BI Service is the one managing high user concurrency.

  • For users on Power BI Desktop building dashboards, the request to TM1 happens only once; most of the work then happens without any further interaction with TM1. It always depends on how large the dataset is that users are importing into Power BI — a dataset can become very large very quickly, so some mentoring or training for Power BI Desktop users is worthwhile to use PowerConnect efficiently (for example, don't bring in all dimensions of a cube you don't need in your report, and filter out attributes you don't need). See PowerConnect Sizing Guide.

Are there known limitations in the interaction with Power BI?

PowerConnect has a timeout of 2 hours for pulling cube data and subset data - which should be more of enough time to pull any reasonable amount of data into Power BI. There are also a couple of MDX constraints: MDX must be passed as a single-line statement, and columns can't be stacked in MDX (rows can). See Troubleshooting MDX.

What role does TM1 memory and server load play?

This depends on how large the dataset is. PowerConnect only does GET requests to TM1, but very large requests might impact other users on the TM1 server. See PowerConnect Sizing Guide.

Installation & Operations

What installation options are available (on-premises / cloud / hybrid)?

All of them: on-premises, IBM PA on Cloud, hybrid, and Cubewise-hosted (Cubewise Cloud). Multi-instance setups are supported. See 🏛️ Architecture and Prerequisites and PowerConnect Hosted on Cubewise Cloud.

Which components need to be installed where?

App Server on a dedicated Windows (or Linux) server; Connector on each user laptop; Microsoft On-premises Data Gateway wherever Service refresh is needed (it can sit on the same machine as the App Server, avoiding extra firewall rules). Prerequisites include an Azure app registration (scope User.Read, admin consent, Power BI OAuth redirect URL) and a full-chain SSL certificate (required for OAuth2 and PA Cloud). See Prerequisites and Installation Guide.

What does a realistic setup and ongoing operational effort look like (including updates)?

Initial setup is config-file driven (settings.yml, copied from a sample), plus license placement and Admin-portal credential setup. Upgrades are essentially "run the installer, next-next-next," occasionally with extra release-note steps, and sometimes redistributing a new .mez connector to users; back up the SSL keys and settings.yml first.

Ongoing effort is modest but includes connector redistribution on connector-breaking releases and gateway maintenance. See Upgrading PowerConnect.

Licensing & Cost Model

How is the licensing model structured (user / server / connector / consumption)?

The PowerConnect license is unlimited servers. There is an enterprise option for unlimited users, or pricing by user.

What costs arise per environment (dev / test / prod)?

Cost is by users, not by servers.

Are there restrictions when running multiple TM1 instances?

Multi-instance is supported. See Configuring the PowerConnect App Server.

Is it possible to obtain a trial version of the connector for a technical evaluation?

Yes — just reach out to your Cubewise local contact for more information.

Target Architecture & Best Practices

For which scenarios do you recommend the connector, and for which would you advise against it?

Use PowerConnect when your destination is Power BI and you want to stay in a TM1 mindset — shape data with views/subsets, reuse existing TM1 security, and get trusted planning numbers into dashboards quickly (Anonymous for trial/POC; OAuth2 + RLS for production). When you instead need TM1 data in a governed warehouse (Snowflake, Databricks) to serve many BI tools, blend with other sources, or move at very high volume/frequency, Atmosphere is the better fit; the two are complementary rather than competing. See PowerConnect vs Atmosphere: Choosing the Right Path for TM1 Data.

How do you position PowerConnect relative to PAW — more as a complementary reporting tool or as a potential alternative for certain use cases?

PAW is for planning and reporting; PowerConnect with Power BI is for reporting only. At Cubewise we always recommend a native TM1 front end like PAW or Apliqo UX. When working with Power BI, it doesn't support all TM1 features and requires extra steps such as setting up Power BI RLS. PowerConnect helps overcome these challenges with Power BI, but Power BI is still not a native TM1 tool.

What does typical usage look like: modelling in Power BI Desktop → publishing → end-user consumption (self-service)?

Exactly that. Model in Power BI Desktop (retrieve views/subsets/security → set data types → build star schema → relationships → RLS), publish to the Power BI Service, map the dataset to the Gateway, set permissions, optionally schedule refresh, and end users consume self-service in a browser or the Power BI mobile app. Security changes in TM1 propagate on the next refresh. See 🎓 PowerConnect Training and Publishing to Power BI Service.

Can data also be downloaded or exported via Power BI?

PowerConnect handles importing the data into Power BI; from there you're in Power BI. You'll need to use Power BI's own features to export.