Feature Requests

Summary Currently, when a component's catalog-info.yaml is updated with new metadata (e.g., adding a Slack channel, updating an owner, or adding a repository tag), the associated Scorecard checks do not reflect these changes until a user manually navigates to the UI and triggers a "Rerun Checks" action. This proposal requests an automated trigger to re-evaluate scorecards whenever the underlying Catalog entity is updated. The Problem Stale Data: Scorecards often show "Failing" grades for checks that have actually been resolved in code, leading to a lack of trust in the dashboard. Manual Overhead: Developers must remember to manually trigger a refresh, adding unnecessary steps to their workflow. Delayed Feedback: There is a "lag" between fixing a metadata issue and seeing the visual confirmation of that fix. Proposed Solution Implement an event-driven refresh mechanism. The system should listen for lifecycle events from the Catalog (specifically EntityUpdated or CatalogUpdate) and automatically queue a scorecard re-scan for the affected entity.

The goal is to move away from static, manual-entry text fields—which are prone to "fat-fingering" and input errors—and move toward a real-time, validated lookup component. Core Functionality Asynchronous Lookup: The UI component should perform an asynchronous GET request to a customer-defined REST API endpoint as the user types. Search Debouncing: To prevent overwhelming the external API, the request should only trigger after a specific character threshold (e.g., 3 characters) or a short delay (300ms) in typing. Key-Value Separation: * Display Value: What the user sees (e.g., "Payment-Processing-Service"). Stored Value: The actual unique identifier (e.g., "V-99827") that is passed into the underlying YAML and used for provisioning. Validation Enforcement: The workflow should prevent submission if the user tries to enter a value that was not returned by the API search, ensuring that only "existing and valid" entities are used.

Core Problem The current UI renders arrays by generating a new, full-width row for every single item added. When a workflow involves multiple inputs (e.g., several environment IDs or service tags), the form becomes excessively long. This "vertical bloat" makes it impossible for users to see the entire form at once and complicates the review of entered data. The Requirement A single input container that "tokenizes" multiple entries into compact, removable pills. Behavior: When a user types a value and presses Enter, the string is converted into a Tag (Pill). Spatial Layout: Tags must wrap horizontally within a single field. The field should only expand its height if the horizontal line is full, rather than creating a new row for every single value. Editing: Each tag must include a clear "X" button for instant removal. Validation: The system should support entering a value, pressing enter, and immediately typing the next one without manual clicks between rows. Specific Use Case In workflows with nested arrays (arrays within other arrays), the current vertical expansion causes a compounding effect where the UI becomes "unbounded." Condensing these into tags ensures even complex, multi-layered forms remain visible within a single screen view.

Problem Statement "Sometimes the color mismatching looks completely different. It should just blend in so the user doesn't have doubts." Currently, there is a significant visual disconnect between the core Harness UI and custom-built Catalog plugins. Because developers must build their own design and CSS styling from scratch, plugins often fail to match the Harness aesthetic. This lack of synchronization creates a fragmented user experience, making custom plugins feel like external, untrusted additions rather than native features. Developers are currently forced to "guess" styles, leading to: Color Mismatching: Inconsistent palettes between the platform and the plugin. Theming Friction: Difficulty supporting Light/Dark mode transitions automatically. Design Silos: High effort required to recreate standard Harness components (buttons, cards, inputs). Proposed Solution The introduction of a Standardized Plugin Boilerplate and Theme Provider SDK. This solution will provide a "Harness-native" foundation for all new plugins, ensuring they inherit the global design system automatically. By exposing Harness design tokens and providing a pre-configured starter kit, developers can focus on plugin functionality while the UI "blends in" by default. Key Functional Requirements Universal Design Tokens: Provide a library of CSS variables (e.g., primary colors, surface backgrounds, font scales) that stay updated with the Harness brand. Theme Provider Wrapper: A wrapper component that detects the user's active theme (Light/Dark/System) and propagates those styles to the plugin's CSS context. Ready-to-Use Boilerplate: A CLI or repository template that comes pre-integrated with the Harness Design System (HDS) styling bridge. Standardized Component Library: Access to lightweight, pre-styled UI elements (buttons, typography, tables) that match the platform’s look and feel. User Benefits Seamless UX: Users experience a cohesive interface where plugins look and feel like native parts of the Harness ecosystem, increasing trust and adoption. Accelerated Development: Developers save hours of CSS work by using a "plug-and-play" boilerplate instead of recreating styles from scratch. Future-Proofing: When the Harness UI evolves or updates its brand colors, plugins utilizing the boilerplate will update automatically without requiring manual code changes. Reduced Cognitive Load: A consistent UI reduces the learning curve for users interacting with new custom-built features.

Proposed Solution We propose a two-tier enhancement to the IDP: A Component Framework: A way to build and publish "Custom Pickers" as reusable libraries. A Visual Canvas: A drag-and-drop interface (similar to Power Platform or Harness) that allows users to assemble workflows using these pre-defined components. Key Functional Requirements Custom Picker Framework: * The ability to define a picker once (e.g., a "Service Selector" or "Cloud Region Picker") and publish it to a central library. Standardized APIs to fetch data into these pickers (e.g., connecting to internal CMDBs or Cloud providers). Visual Drag-and-Drop Editor: A canvas-based UI where users can see an "Inventory of Things" (the components). Ability to drag components onto the stage to generate the underlying YAML automatically. Consistency with Existing Tooling: Mirror the functionality of the existing Project and Org pickers but allow for user-defined logic. User Benefits Efficiency: Reduces the time to create a new workflow from hours to minutes. Governance: By publishing pickers as a library, we ensure every team is using the same approved data sources and input formats. Lower Learning Curve: Users who aren't "YAML-fluent" can contribute to and build their own automation.

Please enable the flag IDP_STO_INTEGRATION for this account so that we can see the STO insights in IDP

Problem at Hand: The current mapping in Harness does not align with the hierarchy used on the NAB side. Ideally: Harness “Organisation” should align with NAB CIOs Harness “Projects” should align with NAB Domains However, over time, the NAB hierarchy (NAB → CIO → Domain → Service) has drifted out of sync with how it is represented in Harness (NAB → Orgs → Projects → Services). Proposal We attempted to use System Entities to replicate NAB’s hierarchy inside Harness: Created one System Entity for CIO Created another System Entity for Domain Differentiated the two using tags The goal was to link Domain as a child of CIO The challenge: We are currently unable to display Domain entities under a CIO in a tabular format, even though we have linked Domain system to CIO system. We already have reliable mapping at the service level. So during service ingestion, we can: Map each service to its corresponding Domain (System) Map each service to its corresponding CIO (System) This effectively reconstructs the true NAB hierarchy inside Harness without relying on the “Hierarchy” construct

Hi Team, Hope you are doing well. My name is Anubhav, and I am part of the National Australia Bank (NAB) team. We have recently started using the Internal Developer Portal (IDP), and I would like to raise a request regarding the current RBAC controls. At the moment, the IDP portal provides access to Catalog, Blueprints, and Envs, with the following available roles: i) View ii) Create/Edit iii) Delete While the View and Delete roles work well for us, the combined Create/Edit role is a challenge from a governance and control perspective. For stronger access control and clearer separation of responsibilities, we would like to request splitting the existing “Create/Edit” role into two distinct roles: i) Create ii) Edit This separation will help us enforce better governance. Our intended model is: Create → assigned only to Senior Engineers Edit → assigned to the broader development team Could you please review this request and let us know if this enhancement can be considered? Thanks and regards, Anubhav

Problem Statement The current Workflows Execution History view lacks the necessary metadata and navigation links to efficiently troubleshoot failed tasks. Users cannot easily correlate a workflow execution (e.g., "Deploy Subscription") with its underlying CI/CD pipeline run, and the filtering capabilities are too limited for environments with high execution volumes. Proposed Enhancements Direct Pipeline Linking (Traceability) Request: Add a direct hyperlink to the specific Harness Pipeline Execution instance associated with each Task ID. Value: Currently, when a workflow status is "failed," users must manually search for the corresponding pipeline in the CI/CD module. A direct link reduces the "Mean Time to Repair" (MTTR) by allowing one-click access to logs. Advanced Filtering & Search Text-Based Search: Implement a global search bar that parses Task IDs and Template names. Enhanced Column Filters: Add the ability to filter by: Project/Organization: Narrow down tasks by specific business units. Status: Quickly isolate "failed" vs. "completed" runs. Date Range: Filter executions within specific time windows. Expanded Metadata Columns Add a "Project" or "Target Environment" column to the main table. This provides immediate context without requiring the user to click into each Task ID. User Experience Impact By implementing these changes, Platform Engineers and Developers will spend less time "hunting" for data and more time resolving infrastructure issues. This transforms the Workflows view from a simple log into a functional diagnostic dashboard.

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.