Feature Requests

Currently, when a group exists in both Azure AD and Harness, but certain users are found only in Azure AD, forcing provisioning from Azure AD fails. This occurs because Azure identifies the user as already present, even though it is not in Harness. We propose a feature to enable account administrators to force-delete users or groups that were provisioned via SCIM. This functionality would allow for a clean refresh of data from Azure AD, resolving synchronization issues without manual intervention.

Currently, when viewing "All Dashboards," it’s difficult to determine which dashboard belongs to whom, especially when the same dashboard name is used repeatedly during cloning. Adding the folder name where the dashboard is located would provide better context and help users identify the origin of each dashboard at a glance.

Restrict sensitive harness permissions in Create Role When app team creates Harness role, Role should always prefix with “abc” (eg: abc Project Admin) If Role is created with Manager User and Invite User – Restrict the Role permission Restrict Usergroup role binding only with abc Role When app team creates Harnes User Group, they can bind Harness role only that prefix with “abc” If the User Group Role binding is created with Non abc role – block the action Restrict UserGroup SAML binding with only harness idmart group When app team creates Harnes User Group, they can bind SAML SSO group that has abc-gp If the User Group SAML SSO binding is created with Non abc-gp – block the action OPA policy that should not allow users to delete a set of variables that we are creating by default in every project, Only Admins could.

We'd like for Harness to be able to track resources that were created by Terraform. For example, if I created a user via Terraform, the Harness UI should be able to know that the user was created via Terraform. We'd additionally like for resources created by Terraform to be forbidden from being accidentally changed so as not to disrupt the state file. We understand there's a way to achieve this with the current RBAC capabilities but having a native feature for this would make the process much easier.

Hi Team, Currently we have an use case to deploy self-managed harness via helm chart, but the init admin user must be registered manually via UI, it will break the automation pipeline and not smooth. So we want to request to add function to the helm chart to support auto register initial admin user and save the admin password to kubernetes secret. Could you please help to review our request and provide any suggestion? Thanks, Kevin

We have a scenario where people are using a process to deploy but it's not actually creating an instance in kube or anything like that but shows in Harness as having an existing deployment. They are unable to delete their service due to the existing instance that doesn't exist... We are trying to avoid giving them force delete option at the account level.