Allow complex queries for Dashboard indicators and enable users to scale indicators
Many people want to make a dashboard indicator from multi-select table fields and the way Maximizer uses the fields makes this useless.
What we should be able to do is derive a bar chart or pie chart from a SQL Query. But currently you can only use a single number result from a query.
Another common dashboard item request is to show a bar chart of the number of notes made by each user for a period of time. It’s a trivial query to write, but at the moment you have to write one for each user.
That leads to the next problem, which is that if I do that and want to display them using thermometer gauges, they can’t be used for comparison because there’s no control over the scale of the gauge.
So the suggestions are:
- Allow use of more complex SQL queries.
- Allow scale to be set for the representational gauges.
Regards,
-
We do not have any finalised plan on whether we will remove support for direct SQL queries in Dashboards or not. As far as we know today, we are not planning to make any change in that area of the software for the upcoming V13 release.
However, in the CRM Live cloud environment, for security reasons, we do not allow users to directly access SQL. Thus, this feature is not supported there.
Joseph
-
Colin Proudman commented
Hi Joseph
Can you confirm that v12 dashboards will continue to work in future version dashboards? I ask because of your comments about direct SQL Server queries. Some customers have paid for the service of setting up their dashboards including developing underlying SQL Server queries, and if those customers have software assurance they will not understand if something they paid for stops working.
Best regards
Colin -
Richard Harris commented
Take a look at QlikView, a very simple to use BI (BD)package that compliments Maximizer / SQL and gives you amazing flexibility to analyse and dashboard the most complex information.
-
Hi Phil,
Thanks for the suggestion. Indeed, you input includes a number of fairly significant suggestions that should probably be broken down into multiple ones.
We are moving away from supporting creations of Dashboards through direct SQL Queries, which is too complicated for us to support and cause all kinds of security issues. The built-in Dashboard is intended to be created by advanced Maximizer users creating the Dashboard through our UI, and not by programmers. There are other tools and report writers out there that supports generic SQL queries. For example, you may look into using MS SQL Reporting Service for your need.
However, I am interested to know some of the Use Case Scenarios (from end user's prospective) that people like to see working, and then we will see how we may support these scenarios in the future.
You said "Many people want to make a dashboard indicator from multi-select table fields and the way Maximizer uses the fields makes this useless.". Can you provide an example of how user want to graph a multi-select table field?
Thanks,
Joseph -
Colin Proudman commented
Also, allow the List Control to take its input from a SQL Query metric (SELECT in this case) not just a saved search. The List Control available fields for columns would be those specified in the SELECT statement. The benefit would be more complex results returned than is possible with saved searches.