Email replies
The two-way loop: issue comments become customer emails, customer replies become new comments. How to keep private notes private, and how to filter who's talking to whom.
How the loop works
- A customer submits your form. Issued creates an issue in Linear or GitHub with the submitted content and any hidden metadata.
- You (or a teammate) leave a comment on that issue.
- Issued picks up the comment via webhook and emails the submitter from a per-project address.
- The customer replies to that email. The reply is parsed and posted as a new comment on the same issue.
Reply email format
Customers reply to an address like:
text
reply+PROJ-1234@issued.devThe token after the +identifies the issue — customers just hit reply, they don't need to preserve anything.
Private comments
Include (ignore) anywhere in a comment to keep it internal. Works on Linear and GitHub alike.
text
(ignore) Internal note: customer on paid plan, prioritise.The flag is just a substring match — put
(ignore)at the start of any comment and it won't become an email. Use this for triage notes, duplicate markers, and internal chatter.Comment author filter
For a broader rule, use each project's Comment Author Filter instead of prefixing every comment. Lists of actor handles on Linear, or GitHub usernames, with two modes:
- Allow list — only comments from these handles become emails.
- Block list — comments from these handles never become emails.
Common uses: add your AI coding agent (so its progress comments don't email the customer), add Linear's automation bot, or whitelist only a few specific support staff.
Deliverability
- Outbound emails are sent through Mailgun with DKIM-signed headers.
- The visible From address on each email is tied to your project slug — customers see a stable, recognisable sender.
- If a submission had no email address, no outbound email is sent (anonymous tickets just live in the issue tracker).
Related
Per-provider behavior for the comment author filter.