The Case for Signals:
Signals are conversation-native work items. They’re tied to a thread or reply, carry a typed payload (Decision, Action, Question, Risk, etc.), and live in Converse so the discussion and the follow-up stay connected.
Creating a ticket alone is a one-shot export: you get an issue in Jira, but you lose the structured link between “what we agreed in Confluence” and “what’s in Jira” unless you manually maintain it.
Signals changes that.
Practical advantages of Signals
Structure — Fields like rationale, severity, due dates, owners, decision outcomes, risk/mitigation map to templates. Jira issues get rich descriptions built from that payload, not a bare title pasted from chat.
Topic ↔ Jira model — The app is built around one parent issue per topic, with follow-ups as sub-tasks (or comments when that fits). Signals fit that model; random ticket creation can fight it.
Traceability — A signal is anchored to where it came from (thread vs reply). “Just a ticket” doesn’t preserve that anchor unless you duplicate context in the issue.
Workflows only Signals do — e.g. Question signals can spawn a continuation topic so the discussion branches cleanly. Plain Jira create doesn’t do that.
Defer Jira — You can record the signal first and Send to Jira when ready (or retry if Jira fails), so Confluence stays the source of truth.
So: tickets are the execution layer in Jira; Signals are the structured, discussion-linked layer in Confluence that can drive those tickets (and keep them honest to the conversation).