Simplify how agents and flows are enabled

• Summary
• Proposed experience
  • Scenario 1: User has sufficient entitlements (Owner role for top-level group)
  • Scenario 2: User lacks sufficient entitlements
• Current experience

Summary

We are aiming to simplify the workflow for enabling flows and agents. There are two scenarios to address described below. The current experience is described below that. We refer to "agents" and "flows" as "items" in this issue to make it easier to read.

Proposed experience

Scenario 1: User has sufficient entitlements (Owner role for top-level group)

Provide a way for the user to enable the item without leaving their current context:

• Display an active Enable button on the item detail page
• On click, present an interface that provides a way for the user to:
  1. Select the top-level group to enable the item in
  2. Select one or more projects within that group where the item should be enabled
• Complete the full enablement without leaving the current context

Scenario 2: User lacks sufficient entitlements

• Replace the disabled/greyed-out button with a Request Enablement action
• Present a request form where the user specifies:
  • Target top-level group
  • Target project(s)
  • Optional: Justification or notes
• Submit the request as a trackable task assigned to the top-level group Owner(s)
• Provide the requestor with visibility into request status (pending, approved, denied)

Current experience

Enabling an item requires multiple navigation steps across different GitLab surfaces:

1. User creates the item and is presented with a greyed out "enable" button and error message
2. User must find the Explore area's item details page
3. Enable the item at the top-level group from the Explore area
4. Return to the project and enable the item again from that context