Copilot in Power BI and Fabric depends on a few tenant controls

I've seen the same thing happen in a lot of tenants lately. Copilot in Power BI suddenly shows up, and the questions start right away. Is it safe to turn on, and where does the data actually go? Who gets to use Copilot in Power BI and Fabric? And how do you keep the answers useful and compliant at the same time? Over the past year Microsoft has made the Copilot admin controls a lot clearer. Even so, many data teams miss the relevant tenant settings in the Fabric admin portal or leave them on the global defaults, which rarely fit what the business or compliance team needs.

Tenant settings decide who gets Copilot in Power BI

For Copilot in Power BI and Fabric, everything starts in the Fabric admin portal under "Tenant settings". That's where the switches for Copilot and the Azure OpenAI Service live. The important part is that you can limit Copilot to selected security groups instead of the entire tenant. If you want to start with a pilot (which is what I usually recommend), create a security group such as "Copilot Power BI Pilot" and add only your data champions or analytics team. You get real feedback and keep the risk low well before a broad rollout.

The second setting to look at is "Allow data processing outside your geo" (cross-geo processing). Since the EU Data Boundary rollout, this one matters a great deal for regulated data. Review it with compliance before you enable Copilot, particularly if you're a European organisation. The Microsoft documentation on the Copilot tenant settings has more detail.

Copilot needs dedicated Fabric or Premium capacity to run

This is where most people trip up. Copilot in Power BI and Fabric only works on workspaces backed by supported Fabric or Power BI Premium capacity. Per-user licences, Premium Per User (PPU) included, are not enough as of today. If a workspace still sits on shared capacity, users get errors instead of Copilot. I've run into this many times. To test Copilot features you need at least a workspace assigned to a Fabric F64 or Power BI Premium P1 capacity, plus group members who have both the right licence and access to the workspace. For midsize organisations that means planning and documenting capacity assignments so cost and control stay in balance.

Answer quality depends on semantic models, RLS and metadata

Copilot's suggestions can be impressive, but they are only as good as the semantic model underneath. Without well-maintained field descriptions, synonyms, verified answers and a proper AI data schema, Copilot returns weak or even misleading results. Models with cryptic or ambiguous names are the worst offenders. In my experience, time spent curating models up front (clear names, solid descriptions) pays off many times over, for Copilot and for classic reports.

Something people often miss is that Copilot fully respects row-level security (RLS). It can only return what the signed-in user is authorised to see, and there is no special bypass. That only helps if RLS is set up correctly in your semantic model, though. Otherwise you risk compliance gaps.

Pro tip: Before you switch on Copilot, ask the data owners to go through every semantic model and check for clear column names, useful synonyms and current descriptions. Even a short review makes a noticeable difference to user trust and answer quality.

A simple diagram shows how Copilot, capacity and permissions depend on each other

The dependencies between tenant settings, capacity and permissions are easier to follow in a picture. Here's a simplified Mermaid diagram I use when discussing a Copilot deployment:

flowchart TD
    CopilotSetting["Copilot tenant setting"] --> SecurityGroup["Security group"]
    SecurityGroup --> User["Users"]
    CopilotSetting --> Capacity["Premium/Fabric capacity"]
    Capacity --> Workspace["Power BI/Fabric workspace"]
    Workspace --> SemanticModel["Semantic model"]
    SemanticModel --> CopilotFeature["Copilot feature"]
    User --> CopilotFeature

Figure: Dependencies for Copilot in Power BI/Fabric at a glance.

If the tenant settings, the capacity assignment or the model quality aren't right, Copilot either can't be used at all or produces disappointing results.

These practices have worked for data and admin teams

This is what I've seen work for data and admin teams in real environments:

• Scope Copilot via security groups, not tenant-wide
• Regularly review and curate semantic models (RLS, synonyms, field descriptions)
• Document workspace capacity assignments and update as needed
• Check cross-geo processing with compliance and legal
• Equip data teams with AI readiness checklists (clear names, data schemas, verified answers)

In the Fabric admin portal → Tenant settings → Copilot and Azure OpenAI Service, you can assign security groups to restrict who has Copilot. It's the safest way to pilot Copilot features without exposing sensitive data or running into licensing problems.

For more technical detail on enablement and requirements, have a look at Microsoft Learn's introduction to Copilot in Power BI.

Copilot in Power BI requires groundwork before it pays off

Whatever the marketing says, Copilot in Power BI and Fabric isn't a switch you just flip. The value, and the safety, come from sensible governance, good models and a targeted rollout. Organisations that simply enable it for everyone tend to end up with messy usage and results nobody is impressed by. Where teams combined tight tenant controls, careful data stewardship and clear rollout phases, I've seen Copilot deliver real value without compliance headaches or confused users. Put some technical and organisational groundwork in place now, and Copilot in Power BI has a much better chance of living up to what it promises.