Feature Requests

Summary: Implement automated service dependency detection and mapping within the Harness IDP (Internal Developer Portal) to reduce manual overhead. Description: Current Behavior: Users must manually define relationships (upstream/downstream dependencies) between components in the IDP. This manual process is time-consuming and prone to errors.. The team is currently manually adding relations for ~94-100 components. Desired Behavior: The IDP should automatically detect and map service dependencies based on code analysis, traces, or existing integrations Example Scenario: If Service B calls Service A and Service C, the system should automatically populate these relationships in Service B's dependency view without manual input. The visualization should clearly show call chains (e.g., "Partner Notification calls Automation Client API, which calls Automation HMS API").

Adding a feature request for adding support to the terraform provider: https://registry.terraform.io/providers/harness/harness/latest/docs for Harness IDP related entities, specifically being able to create workflows.

Harness IDP 2.0 currently supports dynamic field value updates via Form Context and Dynamic Pickers. However, there is no native ability to hide or show arbitrary input fields within the same page in real time, based on other field values. We require the ability to define visibility rules—similar to Angular’s conditional rendering (*ngIf)—directly in workflow YAML, so that the form frontend dynamically changes its layout immediately as a user’s input changes, without navigation or workflow step changes. Example Use Case: Field A (Dropdown): language (values: Go, Python, Java) Fields B, C: Language-specific configuration (e.g., version, build tool) Selecting “Go” should instantly reveal Fields B & C; all other selections hide them. Fields should be displayed or hidden on the same page without reloads. Why This Matters: Removes the need for multi-step workarounds. Aligns Harness IDP UX with modern expectations in frameworks like Angular/React. Prevents user confusion by showing only relevant fields at the right time. Requested Capability: A YAML property (e.g., visibleWhen, ui:visibility) where conditions can be declared based on other field values. Visibility changes should be evaluated live in the current page session, similar to how getContextData updates field values. Should integrate with Form Context for combined scenarios (e.g., data auto-fetch + show/hide). Mock YAML Example: parameters: - title: Language Selection properties: language: title: Language type: string enum: - go - python - java version: title: Go Version type: string enum: - "1.25" - "1.24" ui:visibility: visibleWhen: field: language equals: go buildTool: title: Go Build Tool type: string enum: - "Go Build" - "Make" ui:visibility: visibleWhen: field: language equals: go pythonFramework: title: Python Framework type: string enum: - "Django" - "Flask" ui:visibility: visibleWhen: field: language equals: python Explanation of Mock-Up: The new proposed property ui:visibility controls live rendering of fields. Each field defines a visibleWhen condition referencing another field (language) and a matching value (equals: go). Fields not meeting the condition are not rendered at all on the page until the condition becomes true. Impact if Not Implemented: Onboarding flows require extra page navigation, slowing user progress. Users encounter irrelevant fields, increasing cognitive load. Limits parity with modern app frameworks and rich interactive UX patterns.

Integrate the TechDocs LightBox addon to allow zoom capability in the rendered documentation on the IDP module. Test the integration to ensure it works as expected, allowing images to open in a lightbox on doc pages. This will address the issue where the current method using extra_javascript and extra_css in mkdocs.yml is not functioning on the IDP documentation.

Description: Users are intermittently seeing login prompts for Jira and GitHub on the dashboard, even though the integrations are app-to-app and already authenticated. When the token expires, the UI briefly shows a “Sign In” button, but clicking it immediately refreshes the token and loads the data without requiring a full OAuth flow. While this behavior is technically expected due to token expiry, it results in an inconsistent and confusing user experience. Requested Enhancement: Improve authentication handling so that expired tokens are refreshed entirely in the background, without displaying a login button unless re-authentication is genuinely required.

Currently we have IDP 1.0 and would like to enable IDP 2.0

I need a way to pull IDP metrics. I need to be able to pull these based on date range. the datas I need are Active Users New API New Resources New Workflow New Workflow Execution Scorecards Total Catalog Total API Total Catalog Component Total Custom Plugin Enabled Scorecards Total Customer Checks Total Scorecards

Today Harness IDP workflows cannot call Harness CD APIs directly to create Services, Environments, or Pipelines. Instead, we must trigger an intermediate “orchestration” pipeline in CD, which then performs these actions, adding extra complexity, latency, and failure points. Engineering ask: please provide first-class IDP 2.0 actions (or a supported API surface) that allow workflows to directly create/update Harness CD resources (services, environments, pipelines, config files) using a secure service identity, without needing a middle pipeline hop. This would drastically simplify IDP blueprints, improve maintainability, and make Harness IDP a true one-stop provisioning interface for CD assets.

From the IDP service/component view (CI/CD / executions tab): Users can see the list of previous Harness CD pipeline executions and click Rerun, but: Runtime input parameters cannot be modified before rerun (it blindly reuses the last inputs). If the pipeline has no prior executions, nothing is shown and there is no way to run it from IDP at all. As a result, users must click through to the Harness CD UI to start or parameterize a pipeline run instead of doing it directly from IDP. Use Case (as described by Hari) Hari wants developers to be able to: Stay in IDP and, from the component view, trigger Harness CD pipelines directly for that service. For an existing pipeline, start a new execution while changing runtime parameters (e.g., target environment, image tag, flags) without going to the CD UI. For a new or never-run pipeline, initiate the first execution entirely from IDP, instead of needing a previous run in order to see anything in the executions list. This is part of their goal to use IDP as the front door for deployments and avoid context-switching to Harness CD.

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.