Feature Requests

Problem: We are building an API Governance Dashboard using Harness HD Dashboards and need to filter and report APIs based on their lifecycle and domain. These fields are available in the API catalog entity YAML under spec: apiVersion: backstage.io/v1alpha1 kind: API metadata: name: example-api spec: type: openapi lifecycle: production domain: domain:cards owner: group:account/card_services_team However, the l:idp:catalog entity currently exposes only the following fields for HQL queries: kind name type owner tags identifier entity_ref created_at last_updated_at The nested spec.lifecycle and spec.domain values are ingested into the catalog but are not available as queryable fields. We also noticed that idp:api contains a lifecycle field in its schema, but the field currently does not return any data. Requested Enhancement: Expose the following fields as top-level queryable fields on l:idp:catalog: lifecycle — sourced from spec.lifecycle domain — sourced from spec.domain Alternative: Populate the idp:api entity with the corresponding catalog data so that the existing lifecycle field can be queried and a domain field can also be exposed. Business Need: This capability is required to build an API Governance Dashboard that can: Filter APIs by lifecycle — production, experimental, deprecated Filter APIs by domain — cards, payments, accounts, etc. Identify APIs that are missing lifecycle or domain metadata Track API governance and metadata compliance across the organization Expected Outcome: API lifecycle and domain information should be available as HQL-queryable fields in Harness HD Dashboards, allowing customers to build governance dashboards without maintaining a separate data source or duplicating catalog metadata.

Description Organizations with a large number of GitHub repositories currently have difficulty using the GitHub Pull Requests and GitHub Insights plugins in Harness IDP. Today, after authenticating with GitHub OAuth, the repository selector only displays the initial set of repositories (currently around 100). For organizations with thousands of repositories, this means many repositories cannot be selected even though the user has permission to access them. It would be valuable if the repository selector supported capabilities such as: Pagination through all available repositories. Repository search. Lazy loading or similar mechanisms to efficiently browse large organizations. This would significantly improve the experience for enterprise customers with large GitHub organizations and make the GitHub integrations usable at scale. Example use case In a scenario where a GitHub organization contains approximately thousands of repositories. Authentication and permissions are working correctly, but only the first ~100 repositories are available for selection, preventing them from configuring the integrations for the repositories they need.

In the catalog section we can filter the catalogs based on owner, deployment status, project etc. But there is no column that displays the date/time when that particular catalog was created. This will help us or the users to filter out catalogs that they or their team created on a particular date. For example, a user might want to filter the catalogs in ascending or descending order of the date.

Currently, when a develepor registers their Harness CD service into into the IDP catalog utilizing service auto-discovery it only grabs 4 pieces of information. the ability to read add and read a "metadata" block from the actual service object would allow developers to maintain both their IDP catalog entities as well as their actual service in one space, minimizing human toil and creating one source of truth for the service object. custom parsers for the metadata would be an additional ask to allow for seamless updates of the idp catalog without needing to run manual steps every deployment. The same request would be asked for IACM workspaces, allowing for more seamless cross product data fusion.

Currently, you must be in an IDP stage to utilize the IDP update-feature set of harness native steps. this can limit the ability for things to update their catalog items automatically without creating extra stages within a pipeline, IACM/CD were mentioned as use cases (IACM workspace apply updating the catlog without needing to mandate multiple templated stages be implemented together by dev teams - <IACM STAGE TEMPLATE> -> <IDP STAGE TEMPLATE> vs <IACM STAGE TEMPLATE W/IDP UPDATE BUILT IN>)

Objective Provide a self-service Report Builder capability that allows platform administrators and authorized users to create, manage, and execute reports using data sourced from external or internal REST APIs without requiring application code changes. The solution should enable teams to quickly onboard new reports by configuring API endpoints and report definitions through the UI. Business Need Current reporting requirements vary across teams and systems. Data resides in multiple platforms such as: ServiceNow GitHub Jenkins Harness Kubernetes/OpenShift Nexus IQ Security Platforms Internal Enterprise APIs Building a custom report for every use case is expensive and slow. A generic API-driven report builder provides a scalable solution. Goals Primary Goals Create reports from any REST API. Eliminate the need for custom development for each report. Provide report filtering, sorting, and export capabilities. Allow business and platform administrators to build reports through configuration. Support dashboard vis

We would like Harness IDP workflows to support parameterization of pipeline URLs using runtime variables or platform context, rather than requiring environment-specific values to be hardcoded. Currently, pipeline URLs embedded within workflows contain values that vary across environments, making workflows less portable and increasing maintenance effort. Problem Statement Today, when referencing a Harness pipeline from an IDP workflow, the URL must be fully specified with environment-specific information such as: Harness Host URL Account ID Organization ID Project ID Example: https://citizensbankdev.harness.io/ng/account/N2EzMWI4YjQtNDU4OS00Zj/module/idp-admin/orgs/cfg_sandbox_dev/projects/cfgIDPproject/pipelines/createrepo/pipeline-studio/?storeType=REMOTE&connectorRef=account.cfg_enterprise_gh&repoName=idp_create_repo&branch=feature/create-repo-workflow Where: Harness Host : https://citizensbankdev.harness.io Account ID : N2EzMWI4YjQtNDU4OS00Zj Org ID : cfg_sandbox_dev Project ID : cfgIDPproject

Summary: We need Harness IDP workflows to support sending custom headers, including user email, from the ValidateAndFetch field type. Currently, appendUser works with SelectFieldFromApi, but it does not work with ValidateAndFetch. As a result, workflows that use a button-based validation pattern cannot pass required user context, such as email, to backend APIs. Module IDP Category Feature Request / Enhancement Priority High

We’ve identified an opportunity to improve the user experience around error handling in Harness form/API interactions. Current Behavior: When API calls fail (e.g., via form fields, button actions), the error response is displayed as raw JSON. This exposes technical details directly to end users. Impact: Poor user experience, especially for non-technical users. Makes it difficult for users to quickly understand what went wrong and how to take corrective action. Inconsistent with standard UI/UX practices where errors are typically simplified and contextual. Desired Behavior: Provide clean, user-friendly error messages instead of raw JSON. Ability to: Map API error responses to readable messages Customize or format error messages at the form level Optionally hide technical details while preserving them for logs/debugging Current Interim Approach: We are continuing with raw JSON responses due to lack of alternative options.

Description Many users receive or reference a specific Workflow Execution ID from logs, notifications, audit records, or external integrations. Currently, the Execution History search in Harness IDP (and similarly in other execution history views) searches by workflow-related information (such as workflow name), but it does not return results when a valid execution ID is entered. Current Behavior When searching the Execution History page: Searching by workflow name returns matching executions. Searching by a valid Workflow Execution ID returns no results. Expected Behavior Allow users to search directly by Workflow Execution ID, returning the corresponding execution. This would significantly improve troubleshooting and operational workflows, especially when an execution ID is already known from: Notifications Logs Audit records