Short answer: Drop the "GitHub → List Issues" 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 |
|---|---|---|---|
Repository Owner owner | string | Required | GitHub repository owner — the user or organization login (the part before / in owner/repo URLs). |
Repository Name repo | string | Required | GitHub repository name — the part after / in owner/repo URLs. Not the full URL. |
State state | options | Optional | State. Options: Open, Closed, All |
Labels labels | string | Optional | Comma-separated label names to filter by |
Assignee assignee | string | Optional | Filter by assignee username. Use '*' for any, 'none' for unassigned. |
Sort By sort | options | Optional | Sort By. Options: Created, Updated, Comments |
Per Page per_page | string | Optional | Results per page (max 100) |
{"owner": "e.g. acme-corp","repo": "e.g. my-project","state": "{{trigger.state}}","labels": "e.g. bug, high-priority","assignee": "e.g. johndoe"}
[{"state": "open","title": "Bug: Login crashes","labels": [{"name": "bug"}],"number": 42,"html_url": "https://github.com/acme-corp/my-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.