Feature Requests

Today the ROI Calculator sits on the AI Ticket Triage Overview dashboard, above the widgets teams use day to day. Every time the page is refreshed, users have to scroll past it to get to the triage data. The ROI Calculator is mainly useful when evaluating the app, not in daily operations. Request: move the ROI Calculator to a separate ROI dashboard in the app's dashboard dropdown, so the people who need it can open it there and the Overview shows the operational data first. Note: the ROI Calculator is also where the Manual Triage Parameters are entered for Hours Saved Per Week and Cost Saving Per Week, so those parameters still need a place to be entered.

The situation When you build or update a dashboard, you open one widget after another to edit it. The AI Chat panel opens on its own every time a widget opens for editing. What is missing today There is no setting to turn the AI Chat panel off, and minimizing it does not stick: it opens again on the next widget you edit. If you are not using AI Chat at that moment, you end up minimizing it over and over. The request Once you minimize the AI Chat panel, keep it minimized on the next widgets you open for editing, until you open it again yourself. Or let users turn it off. The outcome You can edit widget after widget without the panel opening each time, and AI Chat is still there when you want it. Options today, if you need this now Minimize the panel each time it opens.

When one report serves all your clients, you pick the client with the company slicer. Export the PDF and you get that client's report, and "Show Slicers in Exported PDF" can hide the slicer. Sometimes you want an online link instead: generate it for one client, present from it, then pass the same link to the client. What is missing is a way to tie a shareable link to a client: Share > Shareable Link only offers a time limit (No Time Limit / Customized Time). There is no setting to tie the link to a client. In a scheduled report, the Save Slicer switch (which controls whether recipients can change a slicer) is not available for the company slicer. The request: When generating a shareable link (from Share, or in a manually sent scheduled report), lock it to the client currently selected in the company slicer. Anyone opening the link sees only that client's data, with no way to switch to another client. The outcome: one report for all clients, and a per-client link you can generate on demand and hand to that client as is. Options today, if you need this now: Export the PDF per client. It is not interactive. Client Portal (ConnectWise and Autotask): it can be set up so each client logs in and sees only their own company's data. Each client needs a portal account; it is not a link. Trade-off worth knowing before voting: the link would still be a public link. Whoever has it can see that client's data until it expires or is revoked.

The situation An average hides how consistent the work is. Two ticket types can share the same average completion time while one is predictable and the other ranges from an hour to several weeks. To answer "are we getting more consistent?" or "which work has outliers?", you need to see the distribution, not one number. What that costs today None of the widget types draws a distribution. Grid, Pivot Table and Card Number summarise each group into single values, and Scatter compares two measures. So teams export their PSA data to Excel and build box plots by hand, every reporting cycle. What we would like A box plot widget type, based on the boxplot charts in the eCharts library that MSPbots widgets are built on: One box per group, such as ticket type, subtype or item: the box spans the 25th to 75th percentile, with a line at the median (ideally with the mean marked too) A choice of whisker rule: to the minimum and maximum, or to 1.5 × the interquartile range with points beyond it drawn as outliers Several boxes side by side within a group, for example one per month or quarter, so you can see whether the spread is shrinking over time Hover shows the numbers behind each box: minimum, 25th percentile, median, 75th percentile and maximum Who this affects Anyone reporting on time-based service metrics, such as completion time, resolution time or first response time, who needs to know not only how fast the team is on average but how consistent it is.

To show the same dashboard filtered differently on different TVs today, you have to build a separate dashboard per value and clone every widget into it. Adding one widget means repeating the work once per dashboard — one client is doing it five times or more for every change. What is missing is a place to attach a filter value at publish time: A rotation entry (Settings > Device Manage > device > Edit > Dashboard List) holds a dashboard, not "a dashboard plus a set of filter values". A slicer's only static value is its load-time Default Value, and in TV mode the slicer falls back to the dashboard's original setting rather than keeping what was selected. The request: When publishing a dashboard to a device, choose which slicer value that device shows — publish to the "Tier 3" screen and it shows Tier 3 only. Allow the same dashboard into one device's rotation several times, each with a different value — so a single screen can cycle through three service boards while you maintain one dashboard. The outcome is one dashboard and one set of widgets instead of one per value. Trade-off worth knowing before voting: with a single dashboard, every screen shows the same widgets in the same layout — only the data changes. Existing per-value dashboards would need to be rebuilt once.

Today, pointing an existing widget at a different dataset only works when the new dataset has the same column structure as the old one. If the structures differ, the widget has to be rebuilt from scratch. Requested behaviour A replace option next to the dataset selection in the widget builder. After the new dataset is selected, a field-mapping screen opens, letting you map the old fields to the new ones — and the mapping then automatically updates everything in the widget that referenced the old fields (filters, sorting, grouping, calculated layers, conditional formatting), not just the displayed columns. Why it matters — this is not only about switching PSA switching from one PSA to another (e.g. ConnectWise → HaloPSA) swapping one integrated tool for another — for example moving between CSAT tools such as Simplesat, BizRatings and SmileBack replacing a templated dataset with a custom one moving from one dataset or dataset version to another (e.g. a SQL-based dataset to an API-based one) In each case the widgets themselves are unchanged in intent — only the field names behind them move. Rebuilding every widget by hand is the part that costs time.

When you build a filter you pick a field, an operator, and a value. Today, if you change only the operator, the values you already selected are wiped and you have to pick them all again. Requested behaviour: when the field stays the same and only the operator changes, keep the selected values if the new operator can still accept them. Clear them only when they genuinely don't fit. Applies to filters across the platform: widget filters, dataset filters, bot trigger filters, and conditional formatting. Workaround today: choose the operator first, then select the values.

The scenario When you share a dashboard with your clients through the Client Portal, the company slicer filters each report down to the viewer's own company. That match is made between the portal user's email and their contact record in your PSA. If a portal user's email has no matching contact in your PSA — a personal address, a typo, or a contact that hasn't been added yet — their company can't be resolved. What we'd like For dashboards exposed in the Client Portal, when the viewer's company can't be resolved, the report should show nothing by default, together with a clear message telling the user to contact their administrator. "We can't identify you" should never resolve to "show more." Current workaround Both steps are worth doing today on any dashboard you share with clients: Enable Strict Mode on the company slicer of that dashboard. Before granting a portal user access, confirm their email exists as a contact under the correct company in your PSA. That match is what drives the company filter. Why it matters Your clients only ever see their own data — that's the entire premise of a client-facing report. Making that guarantee independent of per-report configuration removes a class of setup mistakes, which matters most as portal users get added over time by different people.

What we'd like Colours defined in a conditional formatting rule should render as configured, regardless of the interface theme. Any of these would solve it: Exempt rule-defined colours from the Dark theme's colour handling by default A per-widget option such as "Keep custom colours in dark themes" A global setting under theme/appearance preferences

On Heatmap widgets, long Y-axis category names are cut off (e.g., "INC Network>Conn…", "Endpoint Alert>S…"), making rows unreadable in client-facing reports. There is currently no option in the Widget Builder to give the Y-axis labels more space.