Preferences Scopes and Rules

This page is part of the Preferences (Memory) docs:

How precedence works (global vs workspace vs model)

Preferences can apply at different scopes, and the most specific scope wins:

Model (a specific PBIX / dataset)
Workspace (Power BI Service workspaces only)
Global (everything)

Ask the LLM:

“Create a model-specific rule for this dataset only.” “Make this a workspace default for all datasets in this workspace.” “Make this a global default for all models I work with.”

If the assistant tells you a scope is unavailable, it’s usually because you’re not connected to the right place yet (or your license/deployment mode doesn’t allow it).

Types of preferences (what you can store)

IDs (how items are referenced)

Each saved item has an ID. You usually don’t need to pick it yourself-ask the LLM to create or update the rule and it will manage the ID. If you need to refer to a specific existing item, first ask:

“List saved preferences and show me the IDs.”

If you do need to pick an ID (for baselines or documentation), keep it short and stable, like measure_naming or no_auto_rename, and avoid spaces/special characters.

Scopes (what they mean and when to use them)

Scopes are the most important concept for Preferences because they answer: “Does this apply everywhere, or only here?”

Scope	What it applies to	When you should use it	Requirements
Global	All models you use with this MCP server	Personal defaults, “company-wide” assistant behavior, safe output limits	Always available (unless the tool is hidden in browse-only)
Workspace	All datasets in a specific Power BI Service workspace	Team defaults for a workspace (shared conventions)	Pro tier + connected to Power BI Service
Model	One specific PBIX/dataset	Model-specific conventions (glossary, naming, guardrails)	Pro tier + connected to a model (Desktop or Service)

Important practical notes (user-facing):

If you want workspace-scoped preferences, first connect the MCP server to the Power BI Service dataset in that workspace. Then ask the LLM to save the preference at workspace scope.
If you want model-scoped preferences, first connect the MCP server to the specific model (Desktop PBIX or Service dataset). Then ask the LLM to save the preference at model scope.
On Desktop, “model scope” follows the current PBIX you’re connected to. On Service, it follows the connected dataset.
If you’re in Free tier, you can still use Preferences, but you’ll be limited to a small number of global items.

What happens when you switch models?

Switching the connected model changes which model-scoped preferences apply.

Example:

If you save “For this model only: our fiscal year starts in July”, that rule will automatically stop applying when you connect to a different model.
Workspace-scoped preferences (Service) continue to apply for any model in that workspace.
Global preferences always apply (unless overridden by a more specific scope).

Consultant gotchas (important in real projects)

Desktop model scope follows the PBIX file path. If you rename/move/copy a PBIX, it may be treated as a different “model” for preferences. If that happens, export/import your baseline again for the new file location.
Service workspace scoping prefers workspace IDs (stable). In edge cases where the server can’t resolve a workspace ID, scoping may fall back to the workspace name (which can change). If scoping seems to “move”, reconnect and re-check the active scopes.
Settings behave like server configuration. Use rules/guardrails for “how to work”, and use scopes to control where those rules apply.
Preferences are guidance, not enforcement. Org policy controls (if enabled) can hard-block operations regardless of preferences.

Examples (copy/paste prompts):

Global: “Set a global guardrail: always ask before deleting relationships.”
Workspace: “Save this as a workspace default: measures must have descriptions and display folders.”
Model: “For this model only, remember that ‘GM’ means ‘Gross Margin’ and that the finance calendar starts in July.”

Naming rules

Saved conventions such as:

Measure naming style (PascalCase, prefixes, business glossary)
Display folder standards
Required descriptions
Calculation group naming conventions

Example prompts:

“Save a naming rule: measures use Total* only for additive measures; otherwise use Amount*.” “Save a naming rule: calculated columns must end with (calc) and be hidden by default.”

Guardrails

Saved “do/don’t” rules for safe modeling, such as:

“Don’t delete tables/relationships without asking me to confirm.”
“Don’t create bidirectional relationships unless explicitly requested.”
“Prefer incremental changes; use bulk changes only when asked.”

Example prompts:

“Add a guardrail: never rename measures automatically; always ask me first.” “Add a guardrail: when editing schema, propose a plan + impact analysis before applying changes.”

Aliases (synonyms and mappings)

Useful when your model uses technical names but your team speaks in business terms.

Aliases don’t rename objects in the model; they help the assistant interpret your intent and generate consistent names.

Example prompts:

“Remember that ‘GM’ means ‘Gross Margin’ and ‘COGS’ means ‘Cost of Goods Sold’ for this model.” “Store aliases: ‘Sales Amt’ → TotalSalesAmount, ‘Units’ → UnitsSold.”

Descriptions and tags (for organization)

You can ask the assistant to add descriptions (why a rule exists) and tags (how to group/filter) to rules and aliases.

Prompts:

“Add a short description to this rule explaining why we use it.” “Tag these items with team:finance and project:contoso so they’re easy to find later.”