Group-level inheritance/management (also organization-level)
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Note: We should also do organization-level inheritance/management also, for SM and Dedicated instances that do not use top-level groups in the way they are used in GitLab.com. Whether that should be a separate feature or can be done at exactly the same time, we can determine.
About
Flow creation and enabling is project-oriented currently.
Large customers often have many 100s or even 1000s of projects they maintain, and these customers will not want to have to enable/disable flows or agents for every project individually.
Those customers will also want to be able to create flows that can be used exclusively within their descendant projects and by no others. These would be flows created associated with the group, and private.
Proposal
There are 2 aspects we should enable:
1. Allowing groups to be owners of flows and agents
- Allow flows and agents to be created by maintainers+ of a group and owned by that group.
- Group-level items can be made private and only allowed to be enabled for descendant groups and projects.
- Public group-level items appear in the catalog for everyone.
2. Enabling/disabling at group-level
- A group configures a flow once for all descendant projects within that group (including projects of subgroups)
- All new projects added to that group automatically have the flow enabled also
- The flow can be edited/disabled/enabled once to affect all descendant projects at once
- When we trigger flows for a project, we also look up all flows enabled for ancestor groups and trigger those flows for the project
Features that enabling a group-level should enable
- Agentic chat with Custom Agent Selection
- Triggerable flows
Prior art
Integrations can have group-level management. These are enabled at the group-level and therefore enabled for all descendant projects.