Automatizace sběru podkladů od klientů v n8n

Aktualizováno: 18. 9. 2026

Nejlepší verze klientského projektu je taková, kde v okamžiku, kdy zasednete ke stavbě, už logo, copy i přístup k hostingu leží připravené, typované a ověřené. n8n-nodes-briefgate je komunitní node, který tohle dokáže zařídit sám na self-hosted instanci n8n — nikdo nemusí pamatovat, že má klientovi napsat e-mail, a nikdo nemusí pamatovat, že se má jít podívat, jestli odpověděl.

Tohle je how-to doplněk k BriefGate pro n8n, referenční stránce nodu. Ta dokumentuje každou operaci, pole i událost; tady projdeme čtyři kompletní workflow postavená nad nimi. Pokud tu název pole nebo tvar payloadu není vysvětlený, je na té stránce.

Než začnete

Potřebujete self-hosted instanci n8n — node zatím není ověřený pro přímou instalaci z panelu n8n Cloud, takže dnes běží na Docker, npm nebo kterékoli jiné self-hosted možnosti nasazení n8n (co se změní po ověření, viz Instalace na n8n Cloud).

Nainstalujte ho pod Settings → Community Nodes zadáním n8n-nodes-briefgate, nebo příkazem npm install n8n-nodes-briefgate, pokud si závislosti spravujete sami. Pak v n8n vytvořte přihlašovací údaje BriefGate API s API klíčem z dashboardu BriefGate — při stavbě workflow používejte klíč bg_test_… (chová se normálně, ale nikdy neposílá e-mail ani SMS reálnému klientovi) a na bg_live_… přepněte, až bude workflow připravené jít do ostrého provozu.

Detail, na kterém se lidé chytají: node BriefGate Trigger potřebuje klíč se scope admin, protože registrace webhooku odebírá události za celý účet — intakes:read/intakes:write pokrývají vlastní operace nodu BriefGate, ale tohle ne. Triggeru dejte vlastní přihlašovací údaje se scope admin a všemu ostatnímu užší klíč.

Self-hosted / EU úhel pohledu. Provoz vlastního n8n už sám o sobě drží logiku workflow i přihlašovací údaje na infrastruktuře, kterou máte pod kontrolou. Hostovaná API BriefGate na to navazuje: podle dokumentace ke GDPR se veškerá data zpracovávají výhradně v EU — hosting v Německu, úložiště souborů v Cloudflare R2 s omezením na jurisdikci EU. Dobré vědět, pokud je data residency důvodem, proč si n8n hostujete sami; není to ale samo o sobě důvod, proč zvolit zrovna BriefGate.

Workflow 1 — Nový obchod založí intake automaticky

Spouštěč může být cokoli, co se spustí, když projekt začíná: webhook z CRM (obchod označený jako vyhraný), n8n Form Trigger, nebo obyčejný node Webhook za systémem, který dnes klienty zachytává.

Na nodu BriefGate nastavte:

• Project Name — {{$json.projectName}}
• Client Email / Client Name — namapované stejně
• Items — pevná sada, kterou tým vždy potřebuje na startu, např. logo (Image, required), hero_copy (Long Text, required), wp_admin (Secret, required) — nebo přepněte Specify Items na Using JSON a vložte pole rovnou
• Additional Fields → Chase Schedule — Default (nebo Gentle/Aggressive podle typu klienta)
• Additional Fields → Idempotency Key — {{$json.dealId}}

Idempotency key je důležitý konkrétně proto, že tohle workflow startuje z webhooku: CRM a formulářové služby doručení opakují, a bez idempotency key vytvoří opakované doručení druhý intake pro stejného klienta — opětovné použití stejného klíče místo toho vrátí ten původní.

Spuštěním nodu se klientovi ihned e-mailem pošle odkaz na portál a vrátí se založený intake včetně id, které pak jako intakeId potřebuje každé z dalších workflow.

Workflow 2 — Dokončený intake přistane ve vlastním úložišti

Zatímco workflow 1 věci zakládá, tohle je dokončuje: nic se nemusí kontrolovat ručně, nic se nemusí jít ručně posbírat.

Get Results vrátí typované hodnoty podle klíče položky: souborová/obrázková položka se vrátí jako { url, filename, mime, size, checksum_sha256 } s 24hodinovou podepsanou URL, textová položka jako prostá hodnota. Protože klíče položek jste si sami definovali ve workflow 1, odkazujte se na ně přímo — {{$json.results.logo.url}}, {{$json.results.hero_copy}} — místo procházení neznámého tvaru dat. Podepsanou URL souborové položky pošlete do nodu HTTP Request nastaveného na vrácení binárních dat, pak ji zapište nodem Write Binary File, nebo místo něj použijte S3/MinIO node, pokud tam žijí klientská data. Textové položky můžete rovnou zapsat do JSON souboru vedle stažených souborů.

Položka typu secret (přihlašovací údaje k adminu, API klíč) vyžaduje ke čtení API klíč se scope secrets:read (nebo admin) a její hodnota se přes results vrátí přesně jednou — uložte ji ve chvíli, kdy tohle workflow proběhne, protože každé další volání pak už jen hlásí secret_unavailable: true.

Workflow 3 — Naplánovaný report o tom, kdo vám ještě dluží podklady

Tohle nepotřebuje webhook — jde o pravidelnou kontrolu, ne reakci na událost, hodí se jako pondělní digest nebo denní připomínka sama sobě.

Get Many se zapnutým Return All projde všechny shody místo zastavení na výchozím limitu, takže na vytíženém účtu nic nezmizí za první stránkou. Get Status je pro tenhle krok odlehčený endpoint — vrátí stavy položek, historii upomínek a počet progress.outstanding bez stahování obsahu souborů, což dělá jeho volání jednou na intake v rámci rozvrhu rozumným, ne nákladným. Vyfiltrované výsledky zformátujte do čehokoli, co tým už dnes čte: Slack zprávy, souhrnného e-mailu, nebo řádku připsaného do tabulky.

Workflow 4 — Intake po termínu dostane cílenou upomínku

intake.overdue se spustí jednou, poprvé, kdy si pravidelný sweep všimne, že intake překročil termín a povinná položka pořád chybí — nezávisle na automatickém rozvrhu upomínek, a je určený k informování vás, ne klienta. Díky tomu je rozumným spouštěčem pro upomínku, kterou se rozhodnete poslat sami, navrch k tomu, co už dělá automatický rozvrh upomínek.

Send Reminder spustí upomínku mimo automatický rozvrh. Přepnutí Channel na SMS se u téhle konkrétní události vyplatí zapojit — klient, který týdny ignoruje e-mailové upomínky, je rozumný kandidát na jiný kanál; vyžaduje to funkci sms a kladný zůstatek SMS kreditu. Přidejte druhou větev, která zapíše i do Slacku, ať tým ví, že intake potřeboval ruční zásah, ne jen klient.

intake.stalled se ke stejnému vzoru hodí stejně dobře: spustí se ve chvíli, kdy dojde limit upomínek a chase engine zbylé zruší a předá intake zpátky vám. Přidejte ho vedle Intake Overdue do pole Events triggeru, pokud chcete eskalovat i v tomhle bodě.

Čtení payloadů událostí

Každá z výše uvedených událostí nese intake_id a všechny kromě chase.bounced i project_name. Žádná z nich nenese e-mailovou adresu klienta samotného — záměrně, protože execution log workflow má širší publikum než samotný intake. chase.bounced je jedinou výjimkou, protože jeho smyslem je právě říct vám, která adresa recipient selhala. Pro cokoli dalšího o klientovi volejte Get Status nebo Get Results, místo abyste čekali, že to ponese payload triggeru. Kompletní seznam polí pro všech šest událostí, které trigger podporuje, je v webhooks.md.

Další kroky