← All templates

Software Development

GitHub Issue → Client Update

Clients paying for development work rarely read a commit log and always want to know what changed. This workflow watches for issues closed with a client-facing label, collects them into a Notion release page, posts a plain-language summary to the client channel, and mirrors the item into Linear so internal and external tracking do not drift apart.

6 stepsRequires Zapier Starter or higher25 minMedium
GitHubNotionDiscordLinearFilter by Zapier

What you get

Clients get plain-language release notes derived from real closed work.
Only labelled issues reach the client, so internal churn stays internal.
The release page builds itself as work is finished, not the night before the call.

Workflow blueprint

GI
When this happens
GitHubNew Issue Event
1FI
Filter by ZapierOnly continue if
2NO
NotionCreate Database Item
3DI
DiscordSend Channel Message
4LI
LinearCreate Issue
5GI
GitHubCreate Issue Comment

The full blueprint — every field mapping, example value and the written copy for each message — is included with purchase.

Getting it into Zapier

Build this one from the recipe. The blueprint gives you the exact trigger, action events and field mapping for all 6 steps, so it is a copy-and-paste job rather than a design job.

You need your own Zapier account. Zapier’s Free plan runs single-step Zaps only; multi-step Zaps need a paid plan, and Paths and Webhooks need Professional. How this works →

Not on Zapier?

n8n — import and go

An n8n workflow JSON ships with this template. Import it and all 6 steps arrive on the canvas wired in order, and 2 of the 6 nodes arrive with their fields already filled in — the subject lines, the message copy, the delays, the column names. Every step maps to a native n8n node.

What an import cannot carry is your credentials, and the IDs that only exist inside your own account — which spreadsheet, which channel, which board. Those stay in a sticky note under the node, listing what is already done so you do not retype it, and what is left so you can see it.

Make — build guide

A Make-specific guide ships with this template: every module in order, every field value, and the concept translations that catch people out — filters live on the links between modules, and the schedule lives on the scenario rather than in a trigger module.

Self-hosted n8n has no per-task fee, which is worth knowing if this workflow runs at volume. Platform coverage →

Setup steps

1
Detect the closed issue

Configure this step using the field mapping in the blueprint.

2
Continue only for client-facing labels

Configure this step using the field mapping in the blueprint.

3
Add it to the release page

Configure this step using the field mapping in the blueprint.

4
Post the plain-language update

Configure this step using the field mapping in the blueprint.

5
Mirror the item into Linear

Configure this step using the field mapping in the blueprint.

Implementation notes

  • The label is an editorial decision and should stay one. Without it the client receives every dependency bump and typo fix, and stops reading entirely within a fortnight.
  • Write issue bodies knowing a client may read the first paragraph. Costs nothing, and it makes this workflow possible at all.
  • Say what is on staging versus production explicitly. "Done" means shipped to a client and merged to a developer, and that gap is where trust goes.
  • The comment written back to GitHub matters more than it looks — it tells the next developer that this behaviour has been described to a customer.