Workflows

Workflows umožňují skládat integrační toky z připravených akcí (HubSpot, Jira, Google Workspace a další) a orchestrace je pak spouštěna agenty nebo přímo uživateli. Sekce je zatím v beta režimu.

Kde je najdete

Otevřete Build → Workflows. Záložka Workflows zobrazuje přístupná workflow, vyhledávání a stránkování. Dostupnost Create Workflow a akcí řádků závisí na oprávněních.

Sloupec	Význam
Name	Otevře detail workflow.
Status	Aktivní nebo neaktivní; před použitím spouštěče aktivní stav uložte.
Trigger	Nastavený vstupní spouštěč. Schedule může mít režim On Demand bez pravidelného plánu.
Last run	Relativní čas založení posledního běhu nebo Never. Údaj nepotvrzuje úspěšné dokončení.
Created by	Autor workflow.
Access	Nastavení přístupu.

Záložka Runs sdružuje přístupné běhy. Pro jedno workflow vyhledejte jeho název nebo otevřete jeho detail a zvolte Executions.

Vytvoření nového workflows

1. Vyberte Create Workflow. Pomocí Rename Workflow v liště nastavte název a popis.
2. Otevřete katalog + a přidejte spouštěč. Pro ručně spouštěné demo vyberte Schedule, dvojklikem otevřete uzel a ponechte Schedule Type → On Demand.
3. Znovu otevřete + a přidejte akce z Tools, Agents nebo Operators. Tools vyžadují odpovídající připojení; uzel Agent přístupného agenta.
4. Uzly rozmístěte tažením a propojte výstupní bod se vstupem dalšího uzlu. Dvojklikem nastavte povinné vstupy a pomocí výrazů namapujte dostupné výstupy.
5. Až bude workflow připravené, zapněte Active a vyberte Save Workflow. Změny editoru musí být uložené před jejich použitím.
6. Před sdílením nebo přiřazením agentovi otestujte syntetická data a zkontrolujte běh.

Katalog uzlů

Katalog má záložky Triggers pro spouštěče, Tools pro funkce připojení, Agents pro volání agenta a Operators pro řízení toku. Dostupnost závisí na funkcích organizace a připojeních.

Výběr webhooků se omezuje podle vlastnictví, pokud uživatel nemá Webhooks.ManageAll. Uložení vazby ověřuje přístup editora i autora workflow ke stejnému webhooku v dané organizaci; oprávnění editora se nepřenášejí na autora workflow.

Systémové operátory

Operátory jsou vestavěné uzly pro řízení toku; nepotřebují externí připojení ani přihlašovací údaje.

Iterator

Iterator rozdělí kolekci nebo zadané hodnoty na samostatné větve. Pro každou položku zpřístupní item a její index od nuly index. Následující uzly se spustí pro každou položku zvlášť a podmínky spojnic se vyhodnocují v dané větvi. Použijte jej například pro zpracování řádků nebo samostatné volání agenta pro každou položku.

Aggregator

Aggregator po dokončení větví Iteratoru shromáždí zvolené výstupy. Vrací výslednou kolekci v result a počet položek v count; hodí se pro navazující souhrn nebo společné předání výsledků.

Error Handler

Error handler umožňuje vést selhání uzlu po chybové větvi a zpracovat je řízeným postupem. Při návrhu zkontrolujte podmínky spojnic, schvalování nástrojů a výsledek v bězích workflow, Tool Executions a Audit Logu.

Edge settings (Conditions)

U spojnic mezi uzly lze otevřít Edge settings. V této části se nastavují conditions (podmínky), které určují, kdy se má workflow vydat danou větví.

Nastavitelné položky:

• Label pro pojmenování větve.
• Jedna nebo více pravidel v části Condition.
• Operator (např. Text equals) a porovnávací hodnota.
• Add rule pro přidání další podmínky.

Typické akce a příklady

• HubSpot: GetDealById, GetContactById – čtení dealu/kontaktu před předáním do dalších systémů.
• Jira: GetUserAsync, AssignTicketAsync, CreateTicketAsync – obohacení kontaktu nebo vytvoření ticketu.
• Google Calendar: CreateEventAsync – založení schůzky po úspěšném obohacení dat.
• Google Drive: ListFilesAsync, ReadFileAsync – práce s dokumenty.
• LLM / Webhook: volání modelu nebo webhooku pro doplnění logiky, validaci či notifikaci. Postup vytvoření webhooku najdete na stránce Webhooky.

Best practices

• Validace vstupů: ověřte ID, e-maily a povinné parametry dřív, než navážete další uzly.
• Chyby API: počítejte s chybami integračních služeb (timeout, rate limit) a přidejte fallback.
• Pojmenování: uzly pojmenovávejte podle funkce (např. „Find HubSpot Contact“, „Create Jira Ticket“).
• Bezpečnost: pracujte jen s přístupovými právy, která jsou nutná pro daný workflows; citlivé hodnoty držte v trezoru/sekretech.

Výrazy pro text a přílohy

V poli vstupu uzlu napište /. V části Functions najdete base64() a htmlAttachment() s nápovědou. Do funkce vložte text nebo hodnotu z předchozího uzlu. NODE_ID nahraďte skutečným ID uzlu; vnořené složené závorky jsou součástí syntaxe.

Výraz	Výsledek
{{func.base64(Dobrý den)}}	RG9icsO9IGRlbg== — text UTF-8 zakódovaný do Base64.
{{func.htmlAttachment(<html><body>Demo</body></html>)}}	JSON řetězec s polem obsahujícím jednu HTML přílohu.
{{func.htmlAttachment({{[NODE_ID].result}})}}	Stejná struktura přílohy ze vstupního result. Použijte skutečný výstupní název pole daného uzlu.

Výsledek příkladu s doslovným HTML:

[
  {
    "fileName": "report.html",
    "mimeType": "text/html; charset=utf-8",
    "fileBase64": "PGh0bWw+PGJvZHk+RGVtbzwvYm9keT48L2h0bWw+"
  }
]

Celý výraz htmlAttachment namapujte do attachmentsJson e-mailové funkce, pokud tato funkce uvedenou strukturu přijímá. Připravuje data přílohy; sám e-mail neodesílá ani nepublikuje artefakt konverzace. base64 samo nevytváří objekt přílohy a jeho výsledek není šifrování.

Pokud odpověď obsahuje HTML dokument obklopený komentářem, htmlAttachment vybere první dokument od volitelného doctype a <html> po první uzavírací </html>. Bez začátku HTML zakóduje celý vstup; bez uzavíracího tagu vezme zbývající text od začátku HTML. HTML nevaliduje ani nesanitizuje. Prázdný argument vrátí prázdný řetězec.

Předání výstupů Drive dalšímu kroku

Ověřeno pro dev releasy z 18. září 2026. Dostupnost v produkci nebyla potvrzena. Jde o koncepční příklad s názvy výstupních polí, nikoli o syntaxi výrazů nebo přesné popisky výběru polí.

1. Načtěte seznam souborů přes Google Drive nebo OneDrive.
2. Zkontrolujte Files. Pokud je pole prázdné, ukončete větev výsledkem bez nalezených souborů místo pokusu o čtení.
3. Předejte naplněné pole Files operátoru Iterator. U každé položky před čtením ověřte, že jde o požadovaný soubor.
4. Přečtěte vybraný soubor. Funkce ReadFileAsync pro Google Drive přijímá jeho Name, nikoli Id, a exportuje CSV. OneDrive podporuje název/cestu nebo úplnou adresu souboru Microsoft prostřednictvím příslušné funkce pro čtení.
5. Před zpracováním zkontrolujte výsledek čtení: použitelný Content předejte dalšímu kroku pro zpracování textu. Chybějící nebo prázdný obsah směrujte do výsledku bez obsahu. Pokud OneDrive vrátí pouze ContentBase64, použijte krok podporující binární obsah nebo soubor zpracujte samostatně; nepovažujte jej za text.

Stávající textové výstupy zůstávají dostupné. Workflows, které je parsují, mohou přecházet na strukturovaná pole postupně; migrace není povinná. Automatická aktualizace výstupního schématu existujících uzlů nebyla ověřena. Před změnou mapování zkontrolujte dostupná pole a výstupy zkušebního běhu.

Editace a správa

• V seznamu workflows vyhledejte název/klíčové slovo a otevřete položku.
• Workflow můžete upravit, uložit a opětovně spustit – změny se projeví u nových běhů.
• Doporučeno: po větších změnách otestujte tok na neprodukčních datech (testovací dealy/tickety/kalendář).

Detail a testování workflow

V detailu zkontrolujte spouštěč, propojené uzly, vstupy, výstupy, podmínky a přístup. Změny uložte před jejich použitím. Při hledání chyby postupujte od spouštěče přes jednotlivé uzly; chybějící vstup může způsobit selhání navazujících kroků.

Před sdílením spusťte workflow s testovacími daty. Ověřte také případné změny v cílových systémech, například v Jira nebo kalendáři, a při selhání zkontrolujte Tool Executions a logy.

Kontrola běhů

1. Otevřete Build → Workflows → Runs a vyhledejte název workflow. Pokud nový běh ještě není vidět, seznam obnovte.
2. Zkontrolujte Execution ID, Created At a Status. Potvrzení v chatu ani čas Last run neověřují dokončení.
3. Rozbalte řádek a projděte Node runs a výstupní pole. Stejné běhy daného workflow najdete v jeho detailu v Executions.
4. Pokud je k dispozici odkaz na konverzaci agenta, otevřete jej. U akce připojení zkontrolujte příslušné spuštění nástroje i cílový systém.

Panel History níže zachycuje změny editoru. Nenahrazuje výsledky běhů.

Historie změn

V pravém panelu History lze zobrazit předchozí změny workflow (přidané/přesunuté uzly, počáteční stav) a vracet se k dřívějším verzím.

Sdílení workflow

V části Access / Sharing lze nastavit:

• Visibility (Private / Shared),
• Organization Access (např. Can Use),
• Team Access pro přidání konkrétních týmů.

Tím určíte, kdo může workflow používat nebo spravovat v rámci organizace.

Diagnostika

Při neúspěchu zkontrolujte povinné parametry uzlů a mapování, podmínky spojnic, přístup k připojením a odpovědi externích služeb. V Tool Executions ověřte chybu nebo čekající schválení a v Audit Logu související změny. Pokud jste workflow nedávno upravili, porovnejte aktuální verzi s panelem History.

Časté scénáře

• Sync HubSpot → Jira → Calendar: získání dealu a kontaktu, dohledání uživatele v Jiře, vytvoření ticketu a schůzky.
• Incident intake: vytvoření ticketu, přiložení souborů z Drive a notifikace přes webhook/LLM.
• Onboarding: založení uživatele v interních systémech, přidání do skupin a vytvoření úvodní schůzky.

Ukázkové workflows:

Příklady workflow ukazují propojení více služeb:

Workflow nad úkoly

Spouštěč Task created zahájí workflow po vytvoření nového úkolu ve vybraném pracovním prostoru. Nastavení výchozího agenta pracovního prostoru samo o sobě úkoly nespouští; automatické spouštění nastavte pomocí workflow. Uložení workflow nespustí již existující úkoly. Pro tento událostní spouštěč není dostupné Run; test proveďte vytvořením nového úkolu v daném prostoru.

Před vytvořením testovacího úkolu přepněte workflow v liště builderu do stavu Active a zvolte Save Workflow. Neaktivní workflow události vytvoření úkolu nepřijímá. Task created musí být jeho jediným spouštěčem i kořenovým uzlem; nekombinujte jej s časovým ani webhookovým spouštěčem.

Uzel	Nastavení	Výsledek
Task created (Triggers)	Vyberte pracovní prostor.	Předá nově vytvořený úkol dalšímu uzlu.
Create task (Operators)	Vyberte prostor a vyplňte shrnutí; prompt a stav jsou volitelné.	Vytvoří úkol ve vybraném prostoru.
Update task (Operators)	Vyberte prostor, namapujte ID úkolu a zapněte alespoň jedno upravované pole: shrnutí, stav nebo prompt.	Aktualizuje úkol; nevybraná pole zůstanou beze změny.

Uzly úkolů poskytují taskId, workspaceId, summary, taskStatus, prompt a JSON result. Pro stav úkolu použijte taskStatus (Todo, InProgress, Review nebo Done); samostatný výstup status popisuje dokončení uzlu. Zapnuté prázdné pole prompt v Update task vymaže původní prompt.

Příklad: Task created → Agent → Update task. Vyberte vstupní pracovní prostor, předejte prompt úkolu uzlu Agent a původní taskId uzlu Update task. Stav Review nastavte až po úspěšném kroku agenta. Před rozšířením příjmu ověřte běh workflow i výsledný úkol.

Úprava workflow vyžaduje příslušná oprávnění k workflow. Task created vyžaduje zobrazení úkolů; Create task a Update task jejich úpravu a přístup k vybranému prostoru. Zkontrolujte sdílení workflow i prostoru a nevytvářejte řetězec, který stále zakládá další úkoly ve stejném vstupním prostoru.

V liště builderu použijte výběr přístupu pro kontrolu a uložení sdílení. Sdílení s vlastními týmy a s celou organizací vyžaduje odlišná oprávnění.

Spuštění workflow agentem

V Configuration → System Tools agenta zapněte Workflows, vyberte povolená workflow a uložte přes Submit. Viz nastavení a přístup a reference nástroje.

Na výslovný požadavek uživatele agent zavolá trigger_workflow s ID přiřazeného workflow a řetězcem input. Vstup může obsahovat text nebo JSON serializovaný do řetězce. Volat lze jen přístupná, aktivní a nesmazaná přiřazená workflow. Task created vyžaduje událost úkolu a touto cestou jej spustit nelze. Workflow nemůže ze svého běhového řetězce znovu spustit samo sebe.

Příklad požadavku:

Spusť Docs Workflow Demo jednou s tímto JSON vstupem: {"period":"2026-10","mode":"synthetic"}. Potvrď zařazení; výsledek zkontroluji ve Workflows.

Úspěšná odpověď nástroje potvrzuje předání ke spuštění na pozadí. Nečeká na dokončení a nevrací výsledek workflow do tohoto chatu. Skutečný výsledek ověřte v Runs. Neaktivní autor nebo chybějící oprávnění autora ke spuštění mohou zabránit zpracování i po potvrzeném předání.

Vstup spuštění se automaticky nenamapuje do všech navazujících uzlů. Schedule aktuálně poskytuje stav dokončení, ale nemá výstup s payloadem. Před použitím uživatelského vstupu ověřte výstupy zvoleného spouštěče a explicitní mapování uzlů. Uvedené demo ověřuje spuštění, nikoli automatické předání JSON do uzlu Agent.