Feature Requests

Problem Statement: The current UI experience for DB Governance creates the impression of a broken product for new users and large teams like PayPal. Unexpected Redirection: When a user clicks the "DB Governance" tab, they are redirected out of the module and into Project Settings. This is non-intuitive; users (including PayPal's Database Enterprise team) assume the page failed to load or they have hit a regression. Silent RBAC Blocking: If a user lacks specific permissions, the "Build Policy" button is "silently blocked" by a client-side guard. There is no error message, tooltip, or "Request Access" workflow, leaving the user stuck without a path forward. Onboarding Discoverability: Important buttons are hidden behind secondary navigation (e.g., needing to click a "close" icon to reveal the policy builder) once the redirect occurs. Requested UI Enhancements: Dedicated Module Landing Page: Stop the redirect to Project Settings. Create a dedicated landing page within the DB DevOps module for Governance. If no policies exist, show an "Onboarding/Get Started" state. Explicit RBAC Feedback: If a UI element (like "Build Policy") is blocked by permissions, show a clear visual indicator (lock icon or greyed out) with a tooltip explaining exactly which permission is missing. Direct Navigation to Org/Account Policies: If the user is at the project scope but needs to see policies defined at the Org or Account level, provide a "View Parent Policies" link directly in the module rather than requiring manual scope switching.

Title: DBSchemaApply should resolve changelog from trigger commit SHA, not branch HEAD at runtime Problem: DBSchemaApply reads the changelog from the branch HEAD at the time each step executes, not from the commit SHA that triggered the pipeline. In a trunk-based workflow with sequential multi-env promotion (integration → staging → sandbox → prod), this creates a race condition: User A merges PR → pipeline starts, triggered at commit SHA abc123 Pipeline reaches sandbox stage User B merges PR → main HEAD advances to def456 Pipeline's prod stage now reads def456 — picking up User B's untested changesets and applying them to prod Expected Behavior: DBSchemaApply should snapshot the changelog at <+trigger.commitSha> when the pipeline is triggered, and use that same snapshot consistently across all stages for the lifetime of that pipeline execution — identical to how a git clone at a specific SHA behaves. Workaround Today: Use Harness CI with a GitHub connector to clone at the trigger SHA, then invoke the Liquibase CLI directly. This works but forfeits all native DB DevOps features (drift detection, rollback step, audit dashboard, applied changeset expressions). Ask: Add a gitRef or commitSha input to DBSchemaApply (defaulting to trigger SHA), so the step resolves the changelog at a pinned ref rather than always reading the live branch HEAD.

When using the DBApply step, if there is an error users are required to set up a second run step to parse execution logs for error messages to update ticketing systems, having the errors as an accesible expression during rollback would be really useful.

At this time, the build image that Harness uses is predefined and the only way to modify them is via API endpoints ( https://developer.harness.io/docs/database-devops/overview/#configure-harness-db-devops-image-versions ) For customers that have stricter security requirements, the default image may not always fulfill their needs such that it would be great if they could declare a specific image version when executing DB DevOps workflows in their pipelines.

We need a custom dashboard widget in Harness DB DevOps that displays a summary table showing all instances alongside their most recently deployed tag / running schema version. This is a critical requirement for us to achieve visibility across our entire DB estate from a single view, and is a blocker for us to move forward with Q2 onboarding of our DB deployments. Current Behaviour: The current Dashboards (account-level) show a time-series/historical view of all executions — meaning all tags deployed to each instance are listed, not just the latest one. There is no way to collapse/filter the data to show only the most recently deployed tag per instance. We explored using Step Execution Start Time as a proxy for the latest timestamp, but there is no sort filter available within the widget to surface only the latest record per instance. Expected / Desired Behaviour: A dashboard widget (or dedicated view) that shows a table with the following columns: Instance Name Schema Name Environment Latest Deployed Tag / Running Schema Version The table should show only the most recent tag per instance (not the full deployment history), with filter options for Schema Name, Environment, and Instance Name.

We would like a way to add our custom standards/requirements for changes into Author DB Change context. For example, if we have a requirement where each new table or column must have a comment providing ownership, this requirement must be part of changeset generated.

When managing reference data that ships with the application, it would be nice to automatically sync deltas in from a CSV file like we can using the relational databases using the loadUpdateData change type