There are many reasons why you shouldn’t work on a live production, or PROD, instance. Some of these are obvious, such as the risk of accidentally deleting or changing your data, but there are also performance bottlenecks to consider.
ServiceNow recommends that no development work whatsoever be done on the production instance. They recommend to perform all development in a sub-PRODuction instance and thoroughly test everything that’s affected before deploying to PRODuction. This includes even small changes, such as adding a field to a form, or activating a plugin, updating an access control list (ACL) rule, tweaking a client script or developing reports.
Do: Replicate your ServiceNow data before working with it in PowerBI
ServiceNow recommends to “Always have a back-out plan, which includes backing up all records that will be affected by the change.” Use any smart replication tool available for ServiceNow. Makes a copy of your production ServiceNow data to your own database, either on-premises or on the cloud of your choice, which makes it possible to connect ServiceNow to PowerBI effectively and safely. The benefit is that you can easily blend the replicated data with other data sources or modify the data’s structure for easier reporting, secure in the knowledge that the production data is unchanged.
Don’t: Affect ServiceNow performance by running PowerBI queries on live production data
Connecting PowerBI to ServiceNow production instances directly may significantly affect performance. For bigger ServiceNow instances with a lot of data, this approach won’t work at all because it will take ages to download the data for your report.
The best practice is to create a dedicated reporting database containing a copy of the data, either an on-premise database or one in Azure. Once you have this database replicated, you can connect PowerBI to it. You won’t be impacting ServiceNow and the reports will be much faster.
Do: Know when to replicate with display values and when to keep tables
For simple reports, it’s best to replicate with display values (Reference Fields = Both), and then replicate the display values to your target database. However, it’s worth noting that doing so means only the display value will be displayed.
For more complex reports, we recommend keeping the tables from ServiceNow as they are, and doing joins between the tables once you have them replicated. This gives you more flexibility in the long run.
Do: Have a clear idea of the information you’re trying to convey
This post on the Microsoft PowerBI blog has several useful tips for designing a great PowerBI dashboard, we’ve talked in detail about what makes a good data visualization great, as well as how to identify opportunities hidden in ServiceNow data. We’ve also written about the important differences between operational and strategic reporting. What ties these all together is the importance of having a clear idea of the information you’re trying to convey. A sense of prioritization, simplicity and context are all best practices for your PowerBI reports.