Planning in Fabric IQ brings budgets, forecasts, targets, scenarios, master data, writeback, collaboration, and management reporting into Microsoft Fabric. Teams can compare actuals with forward-looking plans without exporting governed data into separate planning platforms or uncontrolled spreadsheets.

Common capability map

Planning sheets: model and contribute

Planning sheets are the core modeling and data-entry experience. They combine semantic model actuals with forward-looking inputs while preserving dimensions, hierarchies, measures, and security from the governed model.

PowerTable sheets: manage reference and operational data

PowerTable turns database tables and semantic model data into no-code data applications. It is the best fit for assumptions, rate cards, account mappings, project registers, workforce inputs, and other structured data that supports or extends the plan.

• Application layouts: grid, hierarchy, crosstab, Gantt, resource, calendar, and Kanban views.
• Data collection: editable fields, forms, lookups, relationships, attachments, formulas, and calculated columns.
• Process automation: approvals, event-driven automation, notifications, triggers, and webhooks.
• Governance: row and column access controls, audit logs, change history, and slowly changing dimension support.
• Operational collaboration: concurrent editing, comments, @mentions, task updates, status tracking, and time entry.

Intelligence sheets: analyze and communicate

Intelligence sheets provide a no-code reporting and presentation layer over plans, budgets, forecasts, and operational data.

• Build financial statements, management dashboards, storyboards, and paginated reports.
• Compare actuals, plans, budgets, and scenarios with variance calculations and reusable measures.
• Use more than 100 chart types, Gantt charts, cards, tables, Super Filters, and context-aware visuals.
• Apply International Business Communication Standards (IBCS) formatting for consistent financial communication.
• Export presentation-ready PDF, Excel, PNG, and other supported outputs while preserving layout and formatting.

• Actuals remain governed: semantic model data is read-only in the planning experience.
• Plan data is separate: inputs and writeback records are stored in Fabric SQL rather than written into the semantic model.
• One model per plan item: a plan item connects to one semantic model, and that model can't be changed after connection.
• Relationships matter: dimensions from different tables work together only when the semantic model relationships support correct cross-filtering.
• Design for lifecycle stability: renaming a connected semantic model or a workspace containing a plan item can break the item.

Writeback integration patterns

Supported source patterns

Transformation capabilities

Query and source lifecycle

• Create: create a query from a planning measure or add a Planning, PowerTable, Excel, CSV, JSON, or Parquet source.
• Organize: rename, duplicate, delete, and group related queries into folders.
• Refresh: refresh a source or query to apply current dimensions, measures, native values, and transformation steps.
• Audit: review refresh history by execution ID, initiator, start time, duration, and status.
• Reference: copy the query GUID when a formula needs to retrieve query values without importing the measure into the sheet.
• Reuse: add query measures to another planning sheet's Values field so they behave like regular source measures.

Connected-planning patterns

Roles and billing

Infobridge best practices

• Prefer one governed writeback table when multiple sheets contribute to the same consolidated outcome.
• Define a canonical planning grain and dimension mapping before appending or blending data.
• Duplicate a query before risky transformation changes so the original remains available for comparison.
• Group queries by business process, geography, or lifecycle stage and use clear owner-based naming.
• Review refresh history and job consumption during active planning cycles.
• Avoid using file uploads as an undocumented production integration; assign an owner, cadence, and replacement strategy.
• Test RLS and connection identity with representative users before publishing consolidated results.

Illustrative pricing by use case

User sessions:
  (3 × 847) + (25 × 168) + (100 × 37) = 10,441 CU-hours

Automation:
  250 successful jobs × 2 CU-hours = 500 CU-hours

Buffered average:
  (10,441 + 500) ÷ 730 hours × 1.30 = 19.48 CU

Capacity starting point:
  Next standard SKU above 19.48 CU = F32

Illustrative PAYG:
  32 CU × 730 hours × $0.18 = $4,204.80/month

*These examples estimate the cost of a continuously running, dedicated capacity at public retail rates. If Planning shares an existing capacity with sufficient headroom, the immediate incremental capacity purchase could be lower or zero, but Planning still consumes capacity and can cause scaling, overage, or throttling. Estimates exclude reservations or negotiated discounts, OneLake storage, Power BI licenses, networking, data movement, and unrelated Fabric workloads. Replace the sample user counts with the Fabric Planning Capacity Estimator, then validate the result with a pilot, the Capacity Metrics app, the Azure pricing calculator, and your Microsoft agreement.

Planning roles are assigned dynamically through time-bound sessions. Users begin with minimum access and are upgraded when they perform Stakeholder or Planner actions. Fabric workspace roles remain independent and continue to control access to the workspace and its items.

• Restrict Planner and Stakeholder session upgrades to approved security groups.
• Use the capacity-level delegated tenant setting when different business units require different controls.
• Keep plan ownership with a durable team rather than an individual account.
• Document approvers, submission windows, locking rules, version promotion, and exception handling.
• Review capacity consumption and oversubscription warnings before major planning cycles.

CU, CU-seconds, and CU-hours

These units describe related but different concepts. Confusing a capacity rate with accumulated consumption can produce estimates that are wrong by factors of hundreds or thousands.

CU-hours = CU-seconds ÷ 3,600
CU-seconds = CU-hours × 3,600
Average CU over a period = total CU-hours ÷ period hours

F8 monthly capacity supply:
  8 CU × 730 hours = 5,840 CU-hours
  5,840 CU-hours × 3,600 = 21,024,000 CU-seconds

Planning rate conversions

How to read Capacity Metrics: the app reports workload operations in CU-seconds because it measures consumption over short time windows. For monthly planning estimates, sum or convert that consumption to CU-hours. For SKU sizing, divide the CU-hour total by the number of hours in the period, then account for peaks, smoothing, concurrency, and other workloads.

*Average equivalent divides the published session consumption by 730 hours. Actual Fabric capacity behavior still depends on the total workload mix, smoothing, and concurrent demand.

How a billed session works

• Trigger: opening, creating, editing, or otherwise engaging with a plan item starts a session.
• Duration: the session runs for 730 hours, equivalent to 30 days, and can't be ended manually.
• Scope: billing is tracked for each unique tenant, user, and capacity combination.
• Returning users: using additional plan items or workspaces on the same capacity doesn't start another session for the same active role.
• Multiple capacities: the same user creates and is billed for a separate session on each capacity.
• Role upgrades: an upgrade closes and prorates the lower-tier session, then continues billing at the higher tier.
• Role downgrades: downgrades don't occur during an active session; the next session starts from the first successful action after expiry.
• Deletion: deleting a plan item doesn't stop its users' active sessions.
• Paused or deleted capacity: remaining CUs for active sessions are summed and added to the Azure bill.

Charges outside user sessions

Illustrative capacity estimate

Planner:      5 × 847 CU-hours = 4,235 CU-hours
Stakeholder: 25 × 168 CU-hours = 4,200 CU-hours
Viewer:     100 ×  37 CU-hours = 3,700 CU-hours
                                      ----------------
30-day planning sessions:             12,135 CU-hours
Average capacity equivalent:          16.62 CU
With a 30% planning/support buffer:    21.61 CU

This example excludes automation jobs, Infobridge execution, Fabric SQL, OneLake, semantic model queries and refreshes, Power BI, and unrelated workloads sharing the capacity. Microsoft's guidance suggests considering an estimated 30% capacity buffer, but the correct buffer must come from a representative pilot and Capacity Metrics data.

Cost-control practices

• Grant Planner access only to model authors; use Stakeholder for contributors who don't need to modify planning structures.
• Avoid opening plan items for users who only need a separately published Power BI report.
• Keep a user's planning work on one capacity where governance and isolation requirements allow it.
• Restrict session upgrades with tenant settings and security groups, and enable the oversubscription warning.
• Inventory PowerTable automations and Infobridge jobs because their charges aren't included in persona sessions.
• Review billing at the capacity level. Records use "Planning" as the workspace and artifact value and don't identify an actual tenant workspace.
• Use Capacity Planning and the Capacity Metrics app to model shared workload demand and monitor saturation.

What happens after a query or writeback?

Workload activity:                   2 minutes
Warm idle period after activity:   15 minutes
Total compute-billed time:         17 minutes
Remaining time in the hour:        compute at zero
Storage and applicable backups:    billed for the full hour

Why Planning activity can extend SQL compute time

The 15-minute timer applies after database activity stops. Planning behavior can therefore change the effective SQL cost profile:

• Manual writeback: infrequent, grouped submissions can produce short bursts followed by autoscale-to-zero periods.
• Auto-writeback: frequent edits can repeatedly restart the idle window and keep minimum memory online for longer.
• Collaboration: comments and shared planning activity that use the database connection can create additional database operations.
• Downstream consumption: Power BI refreshes, semantic model queries, pipelines, data agents, notebooks, and validation queries can wake or keep the database active.
• System activity: SQL usage reporting includes both user-generated and system-generated T-SQL activity.

Compute conversion and guardrails

• Compute conversion: 1 database vCore corresponds to approximately 2.611 Fabric CU; 1 Fabric CU corresponds to approximately 0.383 database vCore.
• Billing dimension: Fabric compares CPU with normalized memory and bills the higher dimension for each interval.
• Maximum vCore limit (preview): set a per-database ceiling to bound peak consumption on a shared capacity. Current options include 2, 4, or 32 vCores, with 32 as the default.
• Tradeoff: a lower maximum can reduce cost exposure and protect shared workloads, but it can also reduce performance and supported maximum storage.
• Capacity pause: pausing the Fabric capacity stops the entire capacity, not only one database. It isn't the same as SQL database autoscale-to-zero.

Planning cost-estimate treatment

Cost-control practices for Planning databases

• Choose auto-writeback only when near-real-time persistence is worth the possibility of longer online periods.
• Coordinate semantic model refreshes, validation queries, and pipelines so they don't create unnecessary always-warm activity.
• Set a maximum vCore limit for development, test, and smaller planning solutions, then load-test before production.
• Filter Capacity Metrics to SQLDbNative and review Total CU(s), timepoints, rejected operations, and storage metrics.
• Track allocated SQL storage and backup growth even when compute frequently reaches zero.
• Include database activity in the planning pilot; a generic 30% buffer isn't a substitute for measured SQL usage.

Recommended cost allocation models

Sample approval thresholds

Adapt these thresholds to the organization's capacity size, planning calendar, and financial controls. They are governance examples rather than Fabric product limits.

Operating cadence

• Weekly during planning cycles: review active personas, capacity utilization, throttling, automation failures, and forecasted spend.
• Monthly: reconcile Planning billing records, session rosters, successful automation counts, Infobridge activity, and showback allocations.
• Before each new cycle: remove unnecessary access, confirm capacity placement, rerun the estimator, and approve expected session counts.
• Quarterly: review SKU size, reservation coverage, overage, chargeback policy, security groups, and whether planning workloads should remain shared or be isolated.

Cost governance KPIs

Production acceptance checklist

• Plan totals reconcile to the governed actuals and approved baseline
• RLS and workspace access are verified for Viewer, Stakeholder, and Planner personas
• Writeback keys, replacement behavior, and change-history requirements are tested
• Approval, locking, version promotion, and late-adjustment procedures are documented
• Capacity consumption is measured under realistic concurrent planning activity
• Semantic model, workspace, connection, and plan ownership have named backups