When starting with Power Bi Desktop in conjunction with Dynamics 365 Customer Engagement, you are presented with several routes to bring your data into the application. In this week’s blog post, I take a detailed look at four of these avenues, outlining the benefits of each one.

Project Service Automation provides a cornucopia of desirable functionality for organisations wishing to integrate their sales and project management processes tightly. Be careful, though when implementing this app when using custom calculations within Dynamics 365 Customer Engagement, as you may encounter a few issues…

Longstanding Dynamics 365 Customer Engagement professionals will be well versed in the capability to auto-create new entities and fields, based on a data import file. This functionality has been exposed fully within the Common Data Service as well, which naturally means the same kind of issues can crop up.

Keeping things simple is an idea I like to promote at all times, particularly in the world of IT. Adopting this mantra can lead to fewer headaches and, as a recent example involving Azure Template deployments within Visual Studio demonstrates, a much faster resolution to your particular problem.

Migrating across from Microsoft Flow to Azure Logic Apps is ridiculously easy. However, there are some critical feature differences that you must make yourself aware of. One difference relates to how triggers actions work, particularly in tandem with an Azure template.

When you are amid a pesky IT issue, it can be difficult determining whether the problem is down to a bug/system fault or human error. Like this recent example involving Azure Data Factory illustrates, it is generally best to assume the latter, to avoid any prolonged difficulty.

Sometimes in IT, you can hit a brick wall when working with something outside of your comfort zone. When this occurs within a personal testing environment, then it also means that resolving errors, such as IP address assignment for the Windows Server Routing and Remote Access service, can be somewhat challenging…

The ability to consume Application Insights data from directly within Power BI is an excellent feature in what is already a pretty outstanding product. However, there will likely be some steps that you have to follow to ensure that your reporting solution is secured, using an appropriately privileged API key.

We saw a few weeks ago how to utilise Azure Active Directory (AAD) Security Groups to manage Azure SQL database access at scale. When using this feature, you must ensure database changes are deployed out using an AAD administrator account or similar, a task which may be difficult to achieve in an Azure DevOps Pipeline.

When you are amid a pesky IT issue, it can be difficult determining whether the problem is down to a bug/system fault or human error. Like this recent example involving Azure Data Factory illustrates, it is generally best to assume the latter, to avoid any prolonged difficulty.