Developing content for this type of solution includes several topics to consider as with “traditional” Power BI development to be shared via Power BI Service. First you need to identify user requirements. Then you spend time understanding data and identifying the data sources, the relationships between them, and the types of data you are working with. After this, you’re able to clean and transform the data to ensure that it is accurate, complete, and consistent. Next you need to design a model that is optimised for performance, scalability, and usability. This involves creating the necessary tables, columns, relationships, hierarchies, and calculations to support your analysis.
When data and data model is ready, you can choose appropriate visualisations, create interactive elements such as drill-downs and filters, optimise the report layout and ensure accessibility. Finally you need to use time to test your model and visualisations to ensure that they are working correctly and meeting requirements. During the whole process you remember to document the report design, data model, and queries used in the report.
Power BI content development to embed
Power BI Premium enables report and visual embedding. In this blog series I will concentrate on the Power BI developer’s point of view on a solution using some parts from Microsoft “Embed for your customers”. These types of solutions allow developers to build an app that uses non-interactive authentication against Power BI. Usually the report users are external users, and they don’t need to sign in using Power BI credentials to view the embedded content.
(If you are interested in learning more details about a software developer’s point of view, visit Microsoft’s official pages Power BI embedded analytics Client APIs | Microsoft Learn.)
In addition to these, there are things that I needed to take into account in the development work or need my special attention. Below are my key takeaways from the Power BI development projects where the objective was to recreate the old customer portal reports. Many of these are applicable also to Qlik Sense.
Identify restrictions in Power BI to meet customer brand or other UX design requirements and contribute to the development of a good theme file (json).
- Prepare to do some expectation management.
- Identify functionalities not supported when Power BI content is embedded.
- Agree features/functionalities development and setups done in Power BI.
- Do tight collaboration with stakeholders. – Read more in the second part of my blog series.
- Reserve enough time for testing. – Read more in the third part of my blog series.
- Remember to plan and agree on the support process well in advance as usually there are several parties and even tools involved. – Read more in the third part of my blog series.
Power BI restrictions and UX-related requirements
Some customers’ brands might have colors not best for reports accessibility or a font type not supported by Power BI. To tackle these in my experience the development work is easiest to do with a Service/UX designer and with the person responsible for the brand. So, in the early phase of the development work make sure you identify restrictions in the tool to meet brand or other UX-related requirements
Contribute to the development of a good theme file (json). This ensures that all reports have consistent and on-brand colors, fonts, etc. Experienced later that when my customer changed brand colors, it was much easier to implement these changes to all reports. Of course, this type of thinking is relevant in “traditional” Power BI development, but when reports are published outside customer organisations, these issues tend to be even more important.
Expectation management
Prepare to do some expectation management for the customer and testers, if an old existing customer portal is recreated with a new technology. Not all functionalities of the old implementation can necessarily be implemented or they are implemented in a different way. Or the new implementation may have new features or some functionality may be better or sometimes worse compared to the old implementation. During my projects this took time as there was existing portal to be replaced.
To really understand feature and functionality requirements, reserve enough time and sessions with the Business owners or Testers to explore the old solution. In my projects I showed the first draft of the report in the early phase, to get feedback. Noticed also that sometimes the Business owner or Tester do not understand the advantages of an agile way of development. So, it did need some courage to show “not so polished” report versions.
If a totally new customer portal is created, then you probably have much more freedom to introduce visualisation types and report layouts/features. But in this case, I would also prefer to demo as soon as possible the first draft version of a report.
Power BI restrictions and embedding
Ensure you know all the solution requirements and discuss them with the Solution Architect and Software developer whether they all are possible to implement. Especially some Power BI Service-related functionalities you probably need to handle outside the tool:
- Export to PDF
- Save favourites/bookmarks
- Report Subscription
- Hiding reports from certain users
- Embed report size and positions in the customer portal
- Functionality to move from one report to another with portal selections/dropdown lists
Agree on features/functionalities development and setups done in Power BI
These features/functionalities I needed to agree with other stakeholders if they are developed in or outside Power BI:
- Report headers/titles (consider where maintenance of the name changes is easiest)
- Consider if some Filter controls need to be done in the UI/customer portal. E.g., default selections in slicers.
These features/functionalities setups in Power BI need to be agreed upon and tested carefully:
- The format of token values is managed outside Power BI, but need to make sure that RLS rules use the correct formats
- Page view setup
- Page/canvas size, Height and Width
- Mobile layouts
I will continue the story about my own experiences related to tight collaboration with stakeholders, testing and support process planning in the next parts of my blog series.