The ultimate Fabric, Power BI, SQL, and AI community-led learning event. Save €200 with code FABCOMM.
Get registeredEnhance your career with this limited time 50% discount on Fabric and Power BI exams. Ends August 31st. Request your voucher.
I work for a small MIS company that wants to move away from expensive MIS reporting toolsets, and PowerBI looks like the answer to our prayers. However, I have come across a 'limitation' that appears to prevent us from going any further. Let me try and explain. We have a customer with no infrastructure, so we have created an appropriate Reporting Database in an Azure SQL Database. As their developer partner, we need to create the necessary datasets, along with a number of sample reports that we can use as the basis for their Accounts team to learn to create their own. They do not need to know how the tables join together, what the foreign keys are, but they do need friendly field names. Now as I understand it I can use desktop PowerBI to create a dataset that connects to Azure, provides the table definitions and links, and gives the fields friendly names. I could then share the dataset or create an organisation pack. But to be visible someone needs to be part of my organisation. This wont work for our business model, and I am looking for advice on best practise to overcome what I see as a serious impediment to our continued use of PowerBI. Is the only answer for our customer to create emails and/or AD accounts for us on their system, and then use these to develop the necessary datasets and reports? What if there are security and financial restrictions? Any advice would be appreciated
Hi @NickBarnes,
From your description, you are in the different organization from your customer. To share the reports on Power BI side, you can consider using Share a dashboard feature: When you share your dashboard with people outside your organization.
Or just share the .pbix file with your customer, they can view it use Power BI desktop, also can view on service after they publish to the service.
Best Regards,
Qiuyun Yu