doc/user/duo_agent_platform/flows/custom.md
{{< details >}}
{{< /details >}}
{{< collapsible title="Model information" >}}
{{< /collapsible >}}
{{< history >}}
ai_catalog_flows. Disabled by default.ai_flow_trigger_pipeline_hooks. Disabled by default.ai_catalog_project_level_enablement. Enabled on GitLab.com, GitLab Self-Managed, and GitLab Dedicated by default.ai_catalog_project_level_enablement removed in GitLab 18.11.{{< /history >}}
[!flag] The availability of this feature is controlled by a feature flag. For more information, see the history.
Custom flows are AI-powered workflows you create and configure to automate complex, multi-step tasks across your GitLab projects.
{{< history >}}
{{< /history >}}
When you create a custom flow, you select a project to manage it and choose whether the flow is public or private.
Public flows:
Private flows:
You cannot change a public flow to private if the flow is enabled.
Prerequisites:
To view a list of flows associated with your project:
Select a flow to view its details.
You can create a flow from a project, or by using the AI Catalog.
Prerequisites:
{{< tabs >}}
{{< tab title="From a project" >}}
To create a flow:
Select Flow.
In the editor, enter your flow configuration:
{{< /tab >}}
{{< tab title="From the AI Catalog" >}}
Select Flow.
In the editor, enter your flow configuration:
{{< /tab >}}
{{< /tabs >}}
The flow appears in the AI Catalog.
Enable a flow to trigger it from an issue, merge request, or discussion.
When you enable a flow in a project, it is enabled in the top-level group for that project at the same time.
Prerequisites:
{{< tabs >}}
{{< tab title="From the managing project" >}}
To enable a flow:
created, started, succeeded, and failed.{{< /tab >}}
{{< tab title="From the AI Catalog" >}}
To enable a flow:
{{< /tab >}}
{{< /tabs >}}
The flow appears in the group and project Automate > Flows pages. Members of any project in the top-level group can now enable the flow in their project.
A service account is created in the group. The name of the account
follows this naming convention: ai-<flow>-<group>.
If a flow is already enabled in a top-level group, you can enable it in the group's projects.
Prerequisites:
To enable a flow in a project:
The flow appears in the project's Automate > Flows list.
The top-level group's service account is added to the project. This account is assigned the Developer role.
Prerequisites:
To disable a flow:
The flow no longer appears in the project or group, and can't be run. Any service accounts or triggers associated with the flow are also removed.
You must now create a trigger, which determines when the flow runs.
For example, you can specify the flow to be triggered when you mention the flow service account user in a discussion, or when you assign the service account as a reviewer.
When you enable a flow in a project, you also create triggers.
Prerequisites:
To use a flow:
In your project, open an issue, merge request, or epic.
To trigger the flow, mention, assign, or request a review from the flow service account user. By default, the user has the name ai-<flow>-<group>.
For example, if you enable a flow called Security scanner in the GitLab Duo group, the service account user is ai-security-scanner-gitlab-duo.
After the flow has completed the task, you see a confirmation, and either a ready-to-merge change or an inline comment.
[!warning] The service account can access all projects that both:
- You have access to.
- The flow has been added to.
To make changes to a flow without overwriting the original, create a copy of an existing flow.
Prerequisites:
To duplicate a flow:
Edit a flow to change its configuration.
Prerequisites:
Hide a flow to remove it from the AI Catalog.
After you hide a flow, users can't enable it. However, they can still trigger it in the groups and projects it is already enabled in.
Prerequisites:
To hide a flow:
Delete a flow to permanently remove it from the instance.
Prerequisites:
When you enable a flow in a group, a related service account is automatically created. The service account:
[!note] Sharing flow service accounts across multiple top-level groups can create unintended access permissions and security risks.