Feature Requests

Customer has reported that users assigned the ccm-viewer role can still perform Start and Stop actions on servers from the CCM Autostopping Rules UI. Since the ccm-viewer role is intended for view-only access, the customer expects users with this role to be restricted from performing operational actions that modify server states. The customer was previously informed that this behavior is by design. However, they would like to revisit this functionality and have Start/Stop actions restricted for users with view-only access. Current Behavior Users assigned the ccm-viewer role can access the Autostopping Rules UI. These users can perform Start and Stop actions on servers. There is currently no effective restriction preventing view-only users from triggering these operations. Expected Behavior Users assigned the ccm-viewer role should have read-only access to CCM Autostopping. Start and Stop actions should be hidden or disabled for users with view-only permissions. Only users with the appropriate permissions should be allowed to perform Start/Stop operations. Backend authorization should also enforce these restrictions to prevent unauthorized actions through API requests. Enhancement Request Introduce granular RBAC control for Start and Stop operations in CCM Autostopping. The enhancement should: Separate operational permissions (Start/Stop) from view-only permissions. Restrict Start/Stop actions for users assigned the ccm-viewer role. Ensure the UI and backend APIs consistently enforce the assigned permissions. Allow administrators to grant operational permissions independently of read-only access. Business Impact This limitation prevents customers from enforcing a strict separation between users who can monitor Autostopping configurations and users who are authorized to perform operational actions. For NYLI, this is an important access-control requirement to ensure that users with view-only access cannot inadvertently start or stop infrastructure resources.

Hi Team, These points are discussed with Sam, Sujeesh. creating a request to track it further. Enhancement / Feature Tag-change synchronization Self-service configuration management Configuration Execution and Log Visibility AutoStopping Rules export True Dry Run mode Viewer-only RBAC restriction UI-based scheduler configuration due to character limitations i am not able to add more details for each enhancement request. Thanks, Raghavendra

Users who run several AI coding agent sessions at once (for example multiple Claude Code processes, or a laptop plus a cloud workstation) share one Harness MCP sign-in. When one session signs in again, the other sessions can lose their access and have to re-authenticate, often well before they would expect, which interrupts long-running work. Please support multiple concurrent Hosted MCP sessions per user, so signing in from one process or machine does not end the others. This matters for teams that work on several tasks in parallel with AI agents: today they either serialize their sessions or re-authenticate repeatedly.

SMTP Configuration in account level need to add Fire and Forget option. becuase some time our organization email server gateways has high queue and latency and delay for acknowledgement. so we need default option in SMTP Configuration so that all approval email and notification email will not timeout and will be delivery email in queue.

After a Terraform, OpenTofu or Terragrunt plan step runs in Harness IACM, there is no way to download the plan from the execution. Users can only view the plan output in the UI. To feed the plan into other tooling, they have to re-run the plan outside Harness or copy the output by hand. Requested feature Add a Download option on the plan step of an IACM pipeline execution that lets users save: the parsed plan (the JSON representation, equivalent to terraform show -json <planfile>) the human-readable plan output Why it matters Teams can keep a record of what was planned before an apply. Debugging and review: engineers can inspect large plans in their own tools and attach them to change tickets or PRs.

Request for bulk approval functionality to allow approvers to review and approve/reject multiple approvals simultaneously, improving efficiency for teams managing approvals during deployments.

Introduce the ability to scope Resource Groups (or another RBAC construct) to a subset of feature flags within a project, for example based on: * Flag tags * Flag groups or folders * Naming conventions or other logical groupings Administrators should be able to grant users or teams permissions (view, edit, approve, delete, etc.) only for the flags that belong to their scope, while allowing all flags to continue coexisting and being evaluated within the same project. Example Use Case A single project may be shared by multiple product teams (e.g., Payments, Mobile, Growth, and Lending). Each team should be able to manage only the feature flags they own, while remaining isolated from other teams' flags. The application continues to consume all flags from the same project, but administrative access is segmented by ownership. Benefits * Enables multi-team collaboration within a shared project. * Reduces the need to create separate projects solely for access control purposes. * Simplifies governance and RBAC administration. * Improves security by enforcing least-privilege access. * Scales more effectively for enterprise customers with large feature flag deployments. * Aligns administrative boundaries with team ownership while preserving a shared runtime environment.

Today the web editor shows a DIFF change for feature flags when staging a change, but the CR API does not provide the same. Request is to provide DIFF changes for FME CRs either via existing CR API, or a new one.

Enterpris is adopting akeyless. Pls enable native secret manager for akeyless

When a <+secrets.getValue(...)> expression references a secret path that does not exist, Harness currently substitutes an empty or null value and continues pipeline execution without throwing an error. This behavior is silent regardless of whether the secret manager connector is configured to connect via delegate or via Harness Platform, though the Platform (cloud-side) path is particularly opaque since resolution errors are not propagated back to the pipeline at all. The expected behavior is that a missing secret should be treated as a hard failure, and the pipeline should be stopped immediately with a clear error indicating which secret path could not be resolved. This would prevent downstream failures that are difficult to diagnose, in this case, a Kubernetes Job crashing with BackoffLimitExceeded, which appears unrelated to secret resolution. Affected areas: secret expression rendering in Helm values files, Native Helm deployments, secret manager connectors using Platform-side connectivity.