Short answer: Drop the "GitLab → Create GitLab Issue" action anywhere in your workflow, map the inputs from upstream nodes, and publish.
Every field can be mapped from an upstream trigger, AI step, table row, or hard-coded literal.
| Field | Type | Required | Description |
|---|---|---|---|
Project ID or Path project_id | string | Required | Numeric ID or URL-encoded path (e.g. 'group%2Fproject') |
Title title | string | Required | Title. Example: Fix CI pipeline timeout |
Description description | string | Optional | Supports GitLab-flavored Markdown |
Assignee IDs assignee_ids | string | Optional | Comma-separated user IDs |
Labels labels | string | Optional | Comma-separated label names |
Milestone ID milestone_id | string | Optional | Milestone ID. Example: 7 |
Due Date due_date | string | Optional | Due Date. e.g. "YYYY-MM-DD" |
{"project_id": "e.g. 123 or my-group%2Fmy-project","title": "e.g. Fix CI pipeline timeout","description": "{{trigger.description}}","assignee_ids": "e.g. 5, 12","labels": "e.g. bug, P1"}
{"id": 1,"iid": 42,"state": "opened","title": "Fix CI pipeline timeout","web_url": "https://gitlab.com/group/project/-/issues/42"}
Use these fields in downstream nodes for routing, logging, or error handling.
Any of these apps can fire this action as part of a workflow.
Triggered by anything in the catalog. Free tier available. No credit card.