Feature Requests

As a: SEI Admin or Manager I want to: add developers who work across multiple teams or special projects into a team’s configuration So that: their contributions can be included in that team’s metrics, while maintaining visibility and traceability in the org structure. Description: In many organizations, certain developers are part of central or shared product teams and contribute to multiple projects or business units simultaneously. These developers may have a functional manager (permanent reporting line) and a dotted-line manager (temporary project association). To support this structure, SEI should allow admins to manage “Shared Developers” within the Team Node Settings. Acceptance Criteria 1) Add Shared Developers → Admins can add developers to a team node even if those developers already belong to another team. → Once added, the developer’s metrics (PRs, commits, issues, etc.) should be reflected in the team’s dashboard. 2) Display in Org Tree → Developers added as shared contributors should also appear under the team node in the Org Tree, with a visual indicator (e.g., dotted line icon or tag like “Shared Developer”). → The developer should remain visible under their original team as well. 3) Remove Shared Developers → Admins can easily remove shared developers once a project or engagement ends. → Upon removal, the developer should disappear from that team node and associated dashboards but remain intact under their primary team. 4) Data Integrity → When a shared developer is added or removed, all linked metrics should update automatically to ensure accuracy in reports and dashboards. Note: → Shared developer addition/removal actions should be logged for audit purposes. → Ideally, this functionality should extend to both manual and automated (CSV/API) team configurations.

I need the SEI 2.0 update, because I want to add permissions to users who will configure SEI projects in the account.

Add a filtering ability in the team setting to surface all developers with missing Cloud IDs in the SEI 2.0 experience

Hi team, good day, We would like to request the enable of SEI 2.0 for the Invex Account. Currently the default version of SEI is being used and would like to have access to the new model of SEI to use the new features. Sincerely, Izac Salazar.

We prefer that non-admin users do not see the integration failure notifications. Since SEI viewers can’t take action on these notifications anyway, it makes sense to hide them from their view.

Hi Team, As of now: Under Dora Profile- Lead for Change- Merge- Destination Branch Filters Branches selected Manually are not retained toggling between Select all branches & Manul selection. Please look into it & retain manually selected branches until we save entire Dora Profile.

Module admin, viewer roles like SEI Viewer should have Org, Project permissions in it. Currently we need to add SEI Viewer and Account Viewer to get viewer permission for Project Viewer and SEI Viewer.

Add support for considering story creep as part of the grace period settings in the system

Request activation of the SEI_ENABLED feature flag for our account for SkySolutions.

As a user of SEI Insights, I want the ability to select individual Jira projects from a project dropdown, So that I can easily and directly view insights specific to the projects (or repos) I care about, without needing to create or manage collections. Acceptance Criteria: Jira Project or SM Repo Dropdown Availability: A dropdown menu should display all Jira projects or SCM repos associated with the connected Jira instance or SCM Repos. The dropdown should dynamically fetch and display project names with no manual setup required by users. Project Selection Behavior: Users should be able to select one or multiple projects or repos from the dropdown. Selected projects or repos should directly drive the insights displayed on the page. Impact on Insights: Metrics and insights should refresh dynamically to reflect the data from the selected projects or repos, similar to how collections drive insights today. Fallback to Collections: If a user prefers to use collections, the option to select collections should still remain available. Error Handling: If the user doesn’t have access to a specific project, the dropdown should either: Exclude those projects, or Display an appropriate access error message. Who are the users? The primary users for this feature would likely be L1 managers, team leads, or senior leadership who are actively tracking project-level metrics and insights. L1 Managers/Team Leads: These users often need to quickly drill down into specific projects or repositories to monitor team performance, identify issues, and take corrective actions. Senior Leadership: While they may not use this feature on a day-to-day basis, senior leaders may still benefit from high-level comparisons across projects to understand broader trends and overall team efficiency. Why do they want to do this? The intent goes beyond just a UI visual change; it addresses a functional need: Ease of Use & Efficiency: Selecting specific projects directly from a dropdown simplifies the workflow. It avoids the complexity of creating and managing collections, which can be time-consuming for users who only want to focus on a specific project or two. Identifying Bottlenecks or Trends: Users want to drill into individual Jira projects or repositories to identify bottlenecks (e.g., PR cycle time, deployment delays, etc.) or focus on areas needing improvement. It enables project-specific insights, which helps in decision-making and driving performance improvements. Flexibility: While collections work for broader views, users need the flexibility to quickly switch focus to a specific project and immediately see relevant insights without additional configuration.