Feature Requests

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.

In IDP as of now we can only update integration and cannot delete them, we should have an option to delete integrations too

Summary Add first-class Tag support across IDP views—Catalog, Scorecards, TechDocs, and Workflows—to filter, group, and segment entities and insights by customizable key:value tags (e.g., domain:payments, tier:critical, lifecycle:beta, language:go). IDP impact: Tags help users quickly determine where to improve, invest, or deprecate within IDP. Problem / Why Now IDP users lack consistent, native slicing of catalog and adoption data by business/technical dimensions. Scorecard and workflow views can’t be segmented to spotlight gaps or progress by domain, tier, or lifecycle. Teams resort to naming conventions or spreadsheets, slowing IDP-driven decisions. Goals & Outcomes Faster decisions inside IDP: Filter/group IDP views by tag in 1–2 clicks. Targeted adoption inside IDP: Track remediation and campaigns by tagged cohorts. Clear governance signals: Apply standards per tag (e.g., tier:critical requires SLO + on-call) and see status in IDP. Scope (IDP Only) Tag Model Key:value tags with optional org-level allowed keys. Attach to IDP catalog entities: Component, API, Resource, System (optionally Domain/Group). Optional inheritance (System → Components) with explicit overrides. IDP Dashboard UX Global Tag Filter (multi-select chips) on Catalog, Scorecards, TechDocs, and Workflows. Tag Badges on entity cards/details; click applies filter. Saved Views: shareable presets that store tag filters (e.g., “Tier-1 Services”). Group By Tag in scorecards and workflow analytics. Bulk Tagging (RBAC-guarded) in the Catalog. Sources of Truth Tags can come from Git-backed YAML, Catalog Ingestion API, or UI (RBAC-guarded). Configurable precedence (default: Git > API > UI). RBAC & Governance View tags: all catalog viewers. Edit via UI/API: restricted to an IDP Tag Editor role or above. Protected Keys (e.g., tier, domain) editable only by admins/automation. APIs Catalog Entities API supports tag CRUD and search: tags.key=value, tags.key:*. Webhook/event on tag changes for downstream automation (optional). Dashboards in IDP All IDP dashboards (Catalog/Scorecards/Workflows/TechDocs) support Filter by Tag and Group by Tag.

Description: Currently, Harness IaCM only supports string-type variables in workspace configurations under tfVars. This limitation causes issues when Terraform modules require structured types like maps, lists, or objects. When users pass JSON objects as variable values, Harness automatically escapes them as strings, leading to invalid Terraform syntax. For example: tfVars: tags: '{"CostCenter":"X","Department":"Cloud COE"}' is rendered as: "tags": "{\"CostCenter\":\"X\",\"Department\":\"Cloud COE\"}" Terraform expects the variable as an object, not as an escaped string: "tags": { "CostCenter": "X", "Department": "Cloud COE" } This behavior breaks IaC workflows that rely on complex or nested variable structures. Impact: Blocks customers from using non-string variable types in Harness IaCM Workspaces. Affects Terraform configurations expecting native objects, lists, or maps. Causes execution failures and forces customers to use error-prone manual workarounds (e.g., replacing escaped quotes). Suggested Enhancement: Enable multi-type support for workspace tfVars by allowing definitions such as: tfVars: additionalProperties: type: string | map | list | object | boolean This will allow structured variable passing to Terraform without escaping, aligning Harness IaCM behavior with Terraform native variable typing.

Trying to output an error message to the Internal Developer Portal (IDP) execution view if pipeline fails. It shows the output message only if the pipeline succeeds but unable to do so for explicit pipeline failure.

I would like to implement an approval workflow in IDP where the specific manager of the end user submitting the workflow must approve before the pipeline continues. A few points to clarify: This IDP workflow will be used across our internal organization, so end users will come from many different teams. I am aware of how to add approvals manually in Harness. However, my goal is to have Harness automatically assign the approver based on the end user’s manager. For example: If Mr. X initiates the IDP workflow, and his team lead/manager is Y, then Y should automatically be added as the approver for that workflow.

Currently, Harness IDP 2.0 workflows do not support direct HTTP or REST API calls from within workflow steps. This limitation significantly restricts the ability to perform dynamic or programmatic actions (such as creating pipelines, environments, or services) directly from the IDP workflow. To work around this, we’ve been forced to create a separate admin pipeline in Harness CD, which acts as a proxy execution layer. The IDP workflow triggers this CD pipeline via API to perform the actual create/update actions. While this workaround functions, it introduces unnecessary indirection, complexity, and maintenance overhead especially when scaling to multiple automation workflows. Expected Outcome: Ability to perform CRUD operations on Harness entities (pipelines, environments, services) directly from IDP workflows. Simplified architecture: no need for proxy CD pipelines. more seamless user experience. Closer alignment of Harness IDP 2.0 with modern platform engineering and automation us

The Confluence Search Plugin, previously available, has not been migrated to the new Backstage Backend system. As a result, teams are unable to access Confluence content directly within the IDP, impacting productivity and ease of access to documentation. Why It Matters: Accessing Confluence content seamlessly within Harness IDP is critical for enabling teams to find documentation quickly and efficiently. The lack of this feature has been highlighted as a pain point by several teams, who now need to leave the platform to search for resources externally. Request: Coordinate with the plugin owners to assess the feasibility of migrating the Confluence Search Plugin to the new Backstage Backend system. If external plugin owners cannot provide support, consider implementing an internal solution to restore this functionality based on team needs. Impact if Addressed: Improves developer productivity by centralizing access to Confluence documentation within Harness IDP. Enhances user experience by reducing the need to switch between tools, keeping workflows streamlined.

HarnessProjectPicker filtering option - #94497 CAn we have the capability in the HarnessProjectPicker to filter projects based on the metadata of the projects returned for the user .

Is there a way to generate a stand-alone webpage as a reference instead of having users logon to Harness and drilling down to Workflows ? It would be more beneficial to offer a simple webpage that they can connect to instead for the exact workflow and that it would run the workflow as a simple webpage without any harness menus.