Short answer: Drop the "GitLab → GitLab Issue Created" trigger on your workflow canvas, add filters if you want them, and publish. It fires within seconds of the event in GitLab, not on a polling schedule.
Drop it on the canvas. Configure a couple of fields. Publish.
You don’t need to read this. Tiny Command auto-maps every field into the visual picker so downstream nodes can pull values by clicking. We show it here for power users who want to know what’s on the wire.
{"url": "https://gitlab.com/group/project/-/issues/1","state": "opened","title": "TC issue","action": "open","labels": [],"issue_id": 100,"author_id": 12345,"issue_iid": 1,"user_name": "Tester","created_at": "2026-04-11T10:00:00Z","event_type": "issue","project_id": 67890,"updated_at": "2026-04-11T10:00:00Z","description": "test","object_kind": "issue","assignee_ids": [],"milestone_id": null,"project_name": "TC Project","project_path": "tc/project","user_username": "tester"}
Every field below can be referenced by name in any action or filter that comes after this trigger.
| Field | Type | Example |
|---|---|---|
| url | string | "https://gitlab.com/group/project/-/issues/1" |
| state | string | "opened" |
| title | string | "TC issue" |
| action | string | "open" |
| labels | array | [] |
| issue_id | number | 100 |
| author_id | number | 12345 |
| issue_iid | number | 1 |
| user_name | string | "Tester" |
| created_at | string | "2026-04-11T10:00:00Z" |
| event_type | string | "issue" |
| project_id | number | 67890 |
| updated_at | string | "2026-04-11T10:00:00Z" |
| description | string | "test" |
| object_kind | string | "issue" |
| assignee_ids | array | [] |
| milestone_id | null | null |
| project_name | string | "TC Project" |
| project_path | string | "tc/project" |
| user_username | string | "tester" |
One trigger. 10+ downstream actions. Zero glue.