Feature Requests

Currently, BI Dashboard can be deleted using "Move to trash" option while in the dashboard screen and a popup shows "Only administrators can retrieve items from the trash." However as a Harness administrator, we cannot see the trash in UI and there is no API as well for us to view and recover deleted dashboards. We have raised a bug https://support.harness.io/hc/en-us/requests/88042 for this but accordingly this feature request is needed to enable BI Dashboard Trash in UI and allow Harness Admins to restore deleted dashboards.

The Looker Dashboards have a huge area at the top in which any global filters are placed. When placing a filter eg Cost Categories, is it necessary to have both the Cost Category filter and the cost bucket? This doubles the space used and puts useless items into the filters. When viewing on a laptop, the real estate is half the screen. This makes the rest of the Dashboards visualisations very hard to view. Scrolling down the Dashboard can also make a large panel of white appear at the bottom. Sometimes there are 3 levels of scroll bar in the Users view. There is a problem with the way Harness has embedded Looker, which is not allowing dynamic resizing in a good UX design way. Please review

In Dashboards the Filters perform exact matching to visible fields within tiles under the "Tiles to Update" section. The issue arises when there are no Dimensions or Measures that provide the exact value. e.g. Trying to filter for results on a particular EC2 Instance ID, but the ID is part of field value string and not the entirety of the value (aws:backup:source:resource Tag on snapshots for example)

It appears that the parameters by which Harness moves their Recommendations to "accepted" status is too rigid. It doesn't appear to be observing the ticket's resolution field, and is looking at the status, so anything outside of the actual "Done" status won't be accepted We'd like Harness to either allow us to customize the acceptance criteria, or broaden the range.

We would like the ability for our Annual reports to have the ability to set a budget alert based on the monthly budget numbers, and exceeding them beyond a certain level. Currently, the alert is only based on the Annual total cost being exceeded.

We would like a method to take recommendations that are made with CCM and move them into the ignore List via API or through UI. We'd like to mark wildcards and for it to be able to process it. For example, all machines starting with windows-*

When actioning a recommendation Engineers often find the recommendation too harsh or contravenes a SaaS requirement, but they are able to implement a partial action of the recommendation and estimate their own more appropriate amount for the Savings $$$ figure. The integrations with Jira and SNow need to allow for the setting of the new amount when closing the ticket, populating the recommendation in Harness with the new estimated savings amount. They do not do this currently

Allow a recommendation to remain as listed once it has been put into a new "In Progress Status". This gives the engineer a chance to return to the tool to register the action taken and provide a fair estimation of the actual savings gained. Sometimes it takes a few weeks before the savings can be seen in enough data to prove the value of the actioned recommendation. A5t the moment the Engineer only has until the next update, when the recommendation may just disappear! Mad!

The recommendations table can be split by account but not by any other real "value" adding field. Enabling tag values on recommendations would enable us to use tags either on the account or on the resources to meaningfully split recommendations. Ideally this would apply at the cloud account level so we can build different views around more consistent values. Cloud accounts can come and go and maintaining views for Cloud accounts is painful

Description: Requests are available to view, but there is no differentiation between a read request and a write request. This can determine what instance is causing a performance bottleneck. The CUR may already have such a field. Service: Amazon Simple Storage Service Usage Type: USW2-Requests-SIA-Tier1 Unit: Requests Line Item Description: $0.01 per 1,000 PUT, COPY, POST or LIST requests to Standard-Infrequent Access However, there's no direct field that clearly indicates whether a request is a read or write operation. Feature Request: It would be helpful to have an additional field or tag that explicitly categorizes each request type as either a read or write. This would enhance visibility and improve the accuracy of usage analytics and cost attribution across services. Use Case: This would help teams more easily break down and monitor storage interactions based on operation type (e.g., PUT vs. GET), which is critical for optimizing costs and understanding usage patterns.