Pin Visuals to Dynamics Dashboard

Original Spike - 9 min read (Edited for clarity and minor redactions. Core structure remains faithful to the original.)

Handling Power BI Visual Pinning and Dashboard Usage Within Dynamics

Executive Summary

This analysis concludes that Power BI visuals cannot be pinned directly to Dynamics dashboards due to platform boundaries.

While customers can create Power BI dashboards as an alternative, this requires granting them elevated workspace access leading to reduced security and governance compared to the current app-based approach.

Embedding such dashboards into Dynamics is not self-service and requires internal team configuration for each customer, creating operational overhead that scales with customer count.

Providing this functionality would involve a direct trade-off: increased user- flexibility versus reduced security control and increased administrative overhead.

Key Implications

• Customers can create Power BI dashboards in the Analytics workspace in Power BI.
• Customers cannot embed them in Dynamics themselves.
• Each customer dashboard requires internal staff effort to configure.
• Operational overhead increases with number of customers.
• Internal resource required for embedding and ongoing maintenance.

1. Existing Infrastructure

The organisation provides analytical reporting in Power BI based on a core system implemented in Microsoft Dynamics.

1.1 Current Architecture

Analytical reports are built in Power BI. Reports are deployed to each customer's Power BI tenancy in a workspace named Analytics. The users at the customers do not have access to the workspaces. Instead reports are distributed to users via a Power BI App as per best practice. Two app audiences exist:

• Consultants
• Managers

All reports share a single semantic model which has Row Level Security (RLS) applied.

There is also one Power BI report embedded into the Dynamics core application accessible via the main navigation pane. This report receives context from the Dynamics system.

1.2 The Ask

1. Allow Analytics users at the customer to pin visuals from existing Power BI reports to a dashboard inside the Dynamics app.
2. Allow internal staff to create bespoke Dynamics dashboards containing pinned Power BI visuals on behalf of the customers.

2. The Decision

Power BI visuals cannot be pinned to dashboards within Dynamics.

Power BI will not support pinning visuals into Dynamics dashboards by either customers or internal staff.

There are other options available:

1. Power BI dashboards may be created and managed within the Power BI Service.
2. These dashboards may either be:
• Accessed directly in the Power BI workspace.
• Linked or embedded in Dynamics as read-only "views".

3. Technical Viability Assessment

Conclusion: Not feasible within Microsoft's platform boundaries.

Based on my analysis of Power BI and Dynamics capabilities there are the following limitations:

1. Platform Limitations

Microsoft maintains strict separation between Power BI and Dynamics dashboards.

2. No API Support

The Power BI REST API provides no endpoints for creating dashboard tiles outside the Power BI Service.

3. Architectural Mismatch

Power BI dashboard metadata cannot be stored in Dataverse storage.

3.1 What a Custom Workaround Would Involve

While theoretically possible to build a custom solution, it would require overcoming significant technical challenges:

3.1.1 Key Technical Hurdles

1. State Capture Complexity

Power BI doesn't expose visual state (filter pane, slicer selections, PvT dial values) via API. Visuals with user interactions rely on the full report canvas context. Pinning a static image of a visual is possible, but a live, interactive visual cannot be extracted and hosted elsewhere. Any 'pinned' visuals in a custom solution would be a snapshot only.

2. Rendering Limitations

There is no way to render individual Power BI visuals without their full report context.

3. Synchronisation Issues

Custom tiles would break when the source reports are updated.

4. Performance Impact

Each custom tile would require separate Power BI API calls.

3.1.2 Estimated Scale of Effort

1. High Complexity

This would be a major integration project.

2. Long Development Timeline

It would likely span multiple development cycles.

3. Continuous Maintenance

Dedicated resource would be required for updates and ongoing maintenance.

4. Single Point of Failure

It creates a business-critical dependency on a bespoke component with no third party vendor support.

NB. As a developer, I can identify the technical challenges but cannot provide precise cost estimates for custom development work.

4. The Rationale

4.1 Power BI dashboards are workspace-bound artefacts

Power BI dashboards exist only in the Power BI service and must belong to a Power BI workspace.

Dynamics dashboards exist in Dataverse and have no native capacity to host Power BI dashboard tiles.

There is no supported mechanism or API to create Power BI dashboards within Dynamics or to pin Power BI visuals into Dynamics.

4.2 Embedding Power BI is read-only

The existing Power BI embedding in Dynamics authenticates the user, passes the context to Power BI and then renders the report from a Power BI workspace.

However embedding does not allow:

1. Creation of dashboards
2. Pinning visuals
3. Modifying BI artefacts

This is an intentional design constraint of Power BI embedding.

4.3 Workspace and permission model conflicts

Pinning visuals requires Member or Contributor access to the Power BI workspace.

This conflicts with the current abstraction based on an application approach to sharing the reports. This app approach allows us to separate audiences and this fact has been used as a design principle when creating the reports.

Allowing analytics users at the customers to pin would:

• break the curated app consumption. The users would have visibility of the reports via the workspace.
• increase risk of misconfigured dashboards and reports. Can we trust the users' skillset?
• complicate RLS-driven user experiences.
• potentially lead to reports and dashboards being created and shared within the customer's organisation without any governance or oversight from us.

4.4 Security and RLS considerations

• Dashboard tiles inherit RLS from the semantic model.
• Sharing dashboards may show different data per user and lead to user-base confusion.
• Embedding links to these dashboards within Dynamics does not change this RLS behaviour.

5. Commercial & Licensing Implications

5.1 Current Approach (Microsoft-Backed)

1. Predictable Licensing

Uses standard Power BI Pro/Premium licenses.

2. Vendor Support

Fully supported by Microsoft.

3. Scalable

Works for all customers without custom deployment.

4. Maintenance-Free

Infrastructure updates handled by Microsoft.

5.2 Custom Solution Business Impact

1. High Initial Investment

Would require significant development resources.

2. Ongoing Maintenance Burden

Custom code needs continuous updates.

3. Support Complexity

Would create new support categories and training needs.

4. Vendor Risk

Microsoft updates could break custom integrations.

5. Limited Scalability

Each customer customisation would add complexity.

5.3 Customer Experience Considerations

1. Increased Support Needs

Customers would need training on custom functionality.

2. Governance Challenges

Uncontrolled dashboard creation could lead to confusion.

3. Performance Expectations

Custom solutions often have slower performance.

6. Options Considered

6.1 Option 1 - Power BI dashboards created in Power BI Service and embedded or linked in Dynamics

Viable (with constraints)

The workflow would be as follows:

• Users create dashboards in their Power BI Service.
• Dashboards live in the Analytics workspace.
• Internal staff then embed these dashboards on the customer's core Dynamics app.

Characteristics:

• Read-only in Dynamics.
• Live data connection so updates with any data changes.
• Requires Power BI permission to view (in the same way as the current embedded report).

Each customer dashboard would be different so would require a unique configuration in their core Dynamics app. This is not a "rinse-and-repeat£ embedding each time.

6.1.1 Permissions Implication

For a customer user to complete Step 1 (create a dashboard in the Power BI Service), they must be granted Member or Contributor access to the workspace. This has a number of implications:

• It breaks the existing curated app approach.
• It grants users ability to modify existing reports, create new content and share content via email.
• It means we would have to manage all permissions at the more granular workspace / dashboard level abandoning the App based audience management currently in place.

This is a fundamental shift in security, control and support responsibility.

6.2 Option 2 - Pin visuals directly into Dynamics dashboards

Rejected

This is not feasible for the following reasons:

• Not supported by Power BI or Dynamics.
• No API or embedding capability exists.
• Violates workspace boundaries.

6.3 Option 3 - Curated dashboard-style report pages embedded in Dynamics

Viable

This would work as follows:

• Internal team creates report pages designed as dashboards (so a consolidation of visuals from across the report suite).
• These reports would be embedded in Dynamics in the same fashion as the current embedded report.

7. Multi-Tenant Implementation Reality

How Option 1 Would Actually Work

For a single customer :

1. Customer creates dashboard in their Power BI workspace.
2. Internal team updates Dynamic embedding configuration.
3. Updated core app deployed to that customer.

For multiple customers:

1. Configuration Management Challenge

Each customer needs separate embedding configuration.

2.Deployment Complexity

Potentially separate app deployments per customer. Deployment timelines would presumably follow the timeline for the core Dynamics deployments so would not be as timely as customer might expect.

3. Support Overhead

Each customisation increases support burden.

7.2 Limitations to Communicate

Worth calling out the limitations:

1. Not Self-Service

Customers cannot embed dashboards themselves.

2. Fundamental Security Model Change

Requires elevating customer user privileges on the Power BI workspace reducing security, governance and increasing maintenance overhead.

3. Lead Time Required

Dashboard requests require internal team involvement and would presumably be deployed in line with current core development cycle.

4. Scalability Concerns

Manual process doesn't scale to hundreds of customers.

5. UX Concerns

How many dashboards would a customer require? If more than one, how and where would these be integrated into Dynamics?

8. Recommendation to Stakeholders

Based on my analysis:

Option	Description	Technically Viable?	Dev/Resource Alignment & Ability	Commercial Sense	Key Risks / Considerations
Option 1: Power BI Dashboards + Embedding	Customers create in Power BI Service. Internal team embeds in Dynamics.	Yes with constraints.	Medium. Requires process change and ongoing configuration work per customer.	Conditional. Increases value but also overhead. Must adjust security model.	Shifts security to workspace grain. Risks scale linearly with customer count.
Option 2: Native Pinning to Dynamics	As originally requested.	No. Platform limitation.	N/A	N/A	Not possible.
Option 3: Curated Dashboard Reports	Internal team builds "dashboard-style" report pages and embed them in Dynamics.	Yes. Uses existing pattern.	High. Uses current skills. Low risk. Scalable.	Good. Maintains control, costs remain predictable. Enhances current offering.	Does not enable customer self-service.
Option 4: Custom Development	Build a bespoke integration.	Theoretically. High complexity and risk.	Very low. High cost. Long development cycle. Permanent maintenance burden.	Poor. Negative ROI, conflicts with current model. High support costs.	Becomes a mission-critical unsupported liability.

8.1 Recommended Path Forward

1. Enable Option 1 where there is a clear customer need. Use Power BI's native dashboard capabilities.
2. Create user guidance. Help customers navigate between Dynamics and Power BI.
3. Consider Option 3. Develop curated dashboard-style report pages.
4. Monitor for platform updates. Microsoft occasionally adds new integration capabilities.

9. Consequences of Choosing Option 1

Aspect	Reality	Implication
Responsibility	No separation of concern. Customers gain content creation responsibility. Internal team retains configuration and security governance accountability.	Creates a hands-on co-dependent model.
Security	Moves from a curated app-based abstraction to a more granular workspace access model.	Reduces control, increases governance overhead and misconfiguration risk.
RLS & Architecture	Aligns with Microsoft best practice.	Avoids the cost, risk and maintenance of a custom integration
User flexibility	Users can create and modify dashboards using Power BI Service. They can also create, amend and share other elements.	Achieves the core ask but outside the Dynamics infrastructure.

10. Clarification on Dashboard Updates

If a Power BI dashboard is embedded or linked in Dynamics any changes made in Power BI Service (tiles, layout, pinned visuals) are reflected automatically in Dynamics because Dynamics renders a live view of the dashboard.

Dynamics acts as a read-only window into Power BI.

11. Final Notes

This decision aligns with:

• Power BI Service architecture
• Microsoft-supported embedding practices
• Secure, scalable analytics delivery