Feature Requests

IDP follows the Backstage schema; these expressions only resolve within Harness pipelines 4. Selective Stage Execution via IDP Triggering specific stages of a pipeline (e.g., only CI + Deploy to Dev) from IDP is not currently supported - Workaround: Use conditional execution within your pipeline stages we will use the pipeline create via IDP to leverage promotion of apps by the application team , the workaround suggested is hindering the application promotion as the run stops after deploying to dev steps . Issue : Via IDP we need to have a provision pipeline and trigger the pipeline and once the requested steps (CI + Deploy to DEV )are covered we have to make the IDP workflow successful, but the pipeline get hold in the next step for further actions.

Capability to invoke IDP workflow via an API with the user specific token that can trigger actions pipeline with the users RBAC

We have a pipeline where users are able to create a login to an EC2 instance for a limited amount of time. The pipeline runs with Input Variables supplied by the user. They include the server instance, username, password and role. These details are then passed to a bash script which creates the user and then goes into a wait for 4 hours and then removes the user. This works fine. The issue is that the password provided by the user is visible to any other user with access to run that pipeline. I want to be able to set the input variable just for the password to be hidden. Is this possible already, if not then can I request it be added?

We would like the following feature flag enabled for the IDP: IDP_WORKFLOW_EXECUTION_V2

Implement a mechanism allowing users to select and execute specific steps within IDP workflows at runtime. The system would maintain workflow integrity by resolving dependencies between selected steps, preserving execution context, and supporting both UI-based selection and API parameters while ensuring proper state management across non-sequential execution.

Problem Statement Currently in Harness IDP (Backstage-based catalog), only a fixed set of fields are searchable and filterable in the UI. Labels are highly restrictive (Kubernetes-style constraints), which prevents customers from using them for real-world identifiers such as canonical paths. While metadata supports flexible values, metadata fields: Are not searchable Are not filterable Are not first-class citizens in the catalog UI by default This limitation makes it difficult to discover and organize APIs and components at scale. Customer Use Case Customers need to associate meaningful identifiers such as a canonical API path, for example: /benefits/investmentManagement/investmentPlanManagement/accruedTimeInvestmentDocumentManagement/ document.read Requirements: The value must be visible in the API details view The value must be searchable The value must be filterable The solution must work for multiple custom properties, not just one hardcoded field Current Limitations Labels Restricted to [a-zA-Z0-9._-] Max 63 characters Cannot contain / Not all label values are searchable Annotations / Metadata Flexible value support Not searchable or filterable Not indexed for discovery Proposed Enhancement Introduce a way to configure custom catalog fields (labels or metadata) as: Searchable Filterable Displayable in the catalog UI For example: Allow customers to define which metadata. or labels. fields should be indexed Allow admin-level configuration to mark fields as: Search keys Filter dimensions Display columns This avoids the need to request new product changes every time a new property needs to be searchable.

Currently, IDP administrators are unable to impersonate users to view or experience the system from a user’s perspective. This limitation makes it challenging for admins to provide effective user training, troubleshoot issues, and support onboarding. Allowing IDP admins to securely impersonate users would greatly improve the efficiency of training sessions, facilitate faster troubleshooting, and accelerate overall system adoption across teams.

searching by ID in IDP does not work - to reproduce find an IDP entity that has an ID that does not match the description and try and search on the ID - it does not find the entity - it should

When using ui:field: HarnessAuthToken in an IDP workflow input form, the token appears masked correctly in the review screen. However, if the token is passed to a backend pipeline through a trigger pipeline step, the token is exposed in plaintext within the pipeline execution logs under the Inputs section. This does not happen with fields that use ui:field: Secret, which are masked end-to-end as expected.

Right now when we create a new group and try to add existing workflows to it, we need to scroll through 100s of workflows and find the workflow and add it. It would be helpful if we have a search bar and filter for finding the workflows quickly and add it to the group