harness - The Modern Software Delivery Platform®
Create
Log in
Home
Feedback
Feature Requests
Log in to your harness - The Modern Software Delivery Platform® account to give feedback
Log In
Boards
Feature Requests
Powered by Canny
Feature Requests
Anonymous
Feature Requests for Harness. Select 'Category' based on the module you are requesting the feature for.
Details
Category
Select a category
Showing
Trending
Sort
Trending
Top
New
Filter
Under Review
Planned
In Progress
This Fiscal Quarter
Next Fiscal Quarter
Long-term
Pending Feedback
Complete
posts in
All Categories
All Categories
Continuous Delivery & GitOps (1,764)
Continuous Integration (382)
Feature Mgmt & Experimentation (285)
Cloud Cost Management (219)
Feature Flags (100)
Service Reliability Management (10)
Security Testing Orchestration (101)
Chaos Engineering (38)
Software Engineering Insights (114)
General Platform Requests (450)
Internal Developer Portal (119)
Code Repository (41)
IACM (36)
Continuous Error Tracking (13)
Drone 2.x (13)
Open Source (31)
SSCA (13)
Database DevOps (14)
Application and API Posture (0)
Application and API Security (1)
Application and API Protection (0)
Traceable Platform (1)
MTK Monitoring at Granular Level
Customer would like to be able to more granularly monitor their MTKs. They would like to have self-service options for getting the visibility they see from the MTK reports that we can request and share with them. Ideally they would want to be able to see MTKs broken down by flags, by traffic types, and also be able to get notified when they reach their MTK entitlement. Customer implemented pooling to be able to better control their MTKs but they are still seeing higher than anticipated volumes which is leading to a decrease in their trust of the platform and ability to predict what their utilization would be.
4
·
long-term
11
Release bundles (group flags together to turn on or roll back as a unit)
Group releases together to turn on all at once (or roll back). This would be useful give the number of flags they plan to create within each release.
1
·
long-term
3
Navigating from flag to experiment
The ability to navigate from an experiment feature flag, to an associated experiment dashboard. Today, this can only be done from experiment dashboard, back to the feature flag.
2
·
long-term
3
Return the user's email in Get Feature Flag API
In Get Feature flag API ( https://docs.split.io/reference/get-feature-flag ) , currently returning Owner ID, any chance you can add user email in the JSON response? It will help us reduce complexity with bunch of scripts that we are generating for flag hygiene. Currently, I am looping through user details API to get the relevant info.
2
·
long-term
3
Improved tag management
The team would like to be able to enforce tags (e.g. require at least one tag when creating flags) and also edit/manage tags (e.g. pre-populate tags in admin settings for team to use). Due to the # of flags they plan to use, tags will be the key way to keep track of them.
3
·
long-term
5
HMAC for webhooks
Customer is looking to leverage the impressions webhook to create a workaround for MTK monitoring. They are concerned that without HMAC for the webhook and with the potential IP spoofing they would not be able to consume that traffic. Their request would be for security enhancements like HMAC around the webhook.
2
·
long-term
3
IntelliJ plugin
Customer use both VS code and IntelliJ as their IDE. They really like the Vs Code integration and want the same for IntelliJ in terms of finding flags for cleanup via tech debt, arranging flags, seeing status, creating flags with autocomplete.
2
·
long-term
3
Data warehouse Native Integration - Snowflake
Customer use Snowflake as their data warehouse and its important for them to have a data warehouse native integration with it.
1
·
long-term
3
Rudderstack integration
Native Rudderstack integration
1
·
long-term
2
Multiple approval levels
The team would like to be able to require more than one approvers (choose # of approvers) and get more sets of eyes on certain flag changes. Even more specifically, they would like levels of approvers (so approval required by one person, THEN a higher level approver). This is a re-submission of a previous RFE, as they wanted to add that they'd like more than just two (dual) approvals where possible. Also this is now high priority.
4
·
long-term
2
Load More
→
Powered by Canny