Feature Requests

As a user of SEI Insights, I want the ability to schedule reports and receive email notifications for insights, So that I can automatically stay updated on key metrics and trends without manually accessing the platform. Acceptance Criteria: Scheduled Reports: Users can schedule reports for any insight or dashboard. Scheduling options should include: Frequency: Daily, Weekly, Monthly, or Custom intervals. Time: Specific time of day to send the report. Reports should be delivered as downloadable attachments (e.g., PDF or Excel) or via an embedded link in the email. Email Notifications: Users can opt-in to receive email notifications for insights or dashboards. Emails should include: A summary of key metrics/trends. A link to the detailed insights/dashboard in SEI. Any visual elements like charts/graphs (optional but preferred for improved clarity). Configuration Options: Users with appropriate permissions should be able to: Select specific insights/dashboards to include in the report. Customize recipients (individuals or groups). Set report format (PDF, Excel, etc.). Access Control: Email notifications and scheduled reports should respect user permissions. Users without access to an insight or dashboard should not receive reports for that content. Report History: A log of all scheduled reports sent should be accessible within the platform (e.g., under "Reports History"). Error Handling: If a report generation fails, the system should notify the user via email with an error message and a retry option.

Move inline triggert entities to Git?

Current behavior: In the Audit Trail settings (Account: Dev > Settings > Audit Trail > New Streaming Destination), the Streaming Connector step currently offers only Amazon S3 as a destination. Requested feature: Please add Google SecOps (Chronicle) as a supported streaming destination for Audit Trail events, so that we can forward audit data directly to our SIEM. Business justification: Google SecOps (Chronicle) is our SIEM platform. Native support would allow us to centralize Harness audit events with our other security telemetry, without building and maintaining a custom S3-based pipeline.

Please add the EMAIL step for the Build stage type. We are forced to use Custom or Deploy stage to be able to send an email. This is impacting to get metrics as we have jobs which monitor our services which need to use CUSTOM and in the metrics it is being marked as DEPLOYMENT in the deployment metrics but it is not deploying. So to avoid this, we want to move that logic to build so it won't show in the deployment metrics. User also checked the plugin email step for CI but they require native Email step support similar as CD.

Add Pipeline abort to notification events.

We require the Harness Terraform Resource to create an Audit Log Streaming. can we include this resource in the Terraform Resource Documentation?

Currently we do not have the ability to configure the toleration and nodeselector on the gitops services such as gitops agent, Argo CD/Flux services. This shall be helpful for use cases when specific workload needs to be run on specific nodes. Having toleration and nodeselector configuration available on both the k8s manifest and the helm chart shall be helpful.

The ask is to have the platform act as an OIDC Identity Provider, so it can issue short lived tokens that other systems can validate and grant access based on combination of parameters such as workspace/pipeline/environment/workflow/event/repo. Here is workload identity documentation from HCP: https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/workload-identity-tokens and here is another example from github explaining it: https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect We would use this to grant roles and access in a secret management platforms such as HashiCorp Vault or Akeyless. This would enable workflows to either access secrets directly or configure access for other systems, all while avoiding hard coded, long lived secrets.

Harness's gitsync offering is too basic. It had everything for the payload in a single file. It introduced challenges for us for how to separate by environment because all the environment info was in the same file as well (so we could commit changes to CI without it impacting QA or prod yet). We also couldn’t see an easy way to separate workspace setup from individual flag management. So thinking more that, some hierarchical file approach would make more sense so it isn’t a giant blob. We would want those separated so devs aren’t accidentally impacting something they shouldn’t because they were confused what an element was in the file. We do fully understand that approach would overwrite things done in the UI. So I think ideal state is either a 2-way sync like Harness used to have for their CI/CD pipeline stuff OR simply managing specific things via Git and the APIs vs. other things in the UI. For example – flag creation and properties in Git, but flag enablement in the UI so non-engineers can do that work. Still working through what this might mean and other challenges it would bring up, so we don’t need to do it now. But keeping engineers in their normal work area without having to give them direct access to the UI for edit purposes is appealing."

The Centralized Notifications for Pipeline feature ( https://developer.harness.io/docs/platform/notifications/centralised-notification/ ) currently supports DataDog as a notification method but does not include Dynatrace. This request is to add Dynatrace as a first-class integration, making it available as a selectable notification method in the dropdown menu.