- Release Notes
- Getting Started
- Access and Permissions
- Installation and Upgrade
- Interacting with Insights
- Historical data export
- Logs
- Performance and Scalability

Insights
Best practices for dashboard customizations
The ability to customize Insights dashboards is at the heart of the product. By tailoring KPIs, filters, and widgets to your specific needs, you can gain a more precise view of your organization's automation program and business advantages. Custom dashboards offer a wide range of possibilities, from providing a more integrated view of your automation program in Automation Hub, to showcasing the time and money saved through automation in Orchestrator. This best practices section provides ways to create custom dashboards that are efficient and reliable for your organization.
Explores form the basis of the data models that drive the views, entities, and fields you can use while creating and customizing dashboards. Choosing the correct explore is critical to ensure that your desired entities and fields are available when you design a new widget, while also improving overall performance. For example, if you are creating a widget that aggregates the number of queue items over a period of time, it is best to use the Queues explore. If you use something like the Queue ROI explore, this can lead to unnecessary joins, as it combines information related to jobs and ROI, not needed in this context.
The selection of fields and measures provides your organization with the opportunity to enhance their reporting with relevant data that is most significant to your stakeholders. When you select fields and measures, make sure they are part of the same view within Explore. This will help to minimize unnecessary data joins. For example, if you're aggregating queue item manual cost per folder, it's better to use the folder field in the Queues view instead of the Jobs view. If fields and/or measures are necessary across multiple views, consider splitting the widgets.
Maintaining simplicity in widget design is essential for your Insights dashboard. Complex widgets, especially ones that involve pulling data from multiple fields across various explores, can affect performance and response times.
For example, there might be processes that depend on calculating ROI based on the number of times the process has been executed (Process ROI), as well as processes that rely on the number of Queue Items processed (Queue ROI). In these situations, you can combine the two ROI fields. However, this can create complex data joins that result in slower responses, particularly with larger datasets. This performance impact is especially noticeable in on-premises deployments where database performance can be constrained.
If you encounter such issues, the following actions can help improve performance:
- Limit the data range for the widget.
- Increase the database specs (applicable to on-premises instances only).
- If the widgets are primarily used in reports that are sent via email, you can
have two dashboards:
- A dashboard used to generate email reports that combines both fields. Slow performance is less of an issue here, as email reports are not interactive.
- A separate, performance-optimized dashboard for daily use that divides the fields into two distinct visualizations. This dashboard is designed for interactive use and thus prioritizes faster response times.
The number of widgets you include has a significant impact when designing custom dashboards for your organization. If you include too many widgets, this can cause the dashboard to take several minutes to load. At the same time, if you provide too few widgets, this can result in insufficient KPIs or visualizations for users to gain value and take action from.
We recommend including 10 to 15 widgets in a dashboard. This range helps strike a balance between performance and instructional value. Even with data-intensive widgets, the dashboard should function smoothly and efficiently. Furthermore, it allows for a good variety of KPIs and data sources, promoting a comprehensive and beneficial view of your metrics.
For more information on dashboards, check the Dashboards page.
Dashboard and widget filters are crucial in allowing users to segment their data effectively, providing a tailored view of the most important metrics to their particular use case. By focusing on the most relevant information, filters can enhance decision-making and bolster efficient performance across all your robots, processes, regions, and business units.
If the dashboard load time becomes extensive, we recommend you narrow the date range of the dashboard. This action can improve performance and reduce the volume of data over which the widgets are computed. Additionally, if certain widgets prove more problematic than others, apply widget-level date filters to boost widget performance.
For more information on filters, check the Dashboards page.
Custom variables allow your organization to send more specific details regarding process and queue item executions. This enriched data can assist in identifying trends, bottlenecks, or areas in need of improvement, supporting more informed decision-making across your organization.
Custom variables are the recommended approach to import custom data into Insights, and should be used instead of sending business information/data via robot log messages. Sending the message field of robot logs for business data can result in performance degradation and increased dashboard load times due to the large volume of logs the query has to search through.
Make sure that the database account has permissions to terminate queries. This requires the account to have sysadmin privileges or the Alter Any Connection permission. This setting is beneficial for performance as it enables Looker to end a SQL query if a user closes their session or cancels the page load. For example, it's common for users to reload a page when it's slow to load. Each reload queues a request, and without the necessary permission to terminate queries, each reload could aggravate the issue.
When investigating a problem or creating a dashboard, reduce the data. For example, if you're building a report that queries three years of data, creating or debugging the dashboard will be more manageable when querying a smaller data scale, like the data from the past 30 days.
When debugging, consider relocating potentially problematic widgets to their own dashboards. An issue with the entire dashboard could in fact stem from a single widget. Hence, isolating that widget can assist in correctly identifying and addressing the problem.