Skip to main content
Logic functions are server-side TypeScript functions that run on the Twenty platform. They can be triggered by HTTP requests, cron schedules, or database events — and can also be exposed as tools for AI agents.
Každý soubor funkce používá defineLogicFunction() k exportu konfigurace s obslužnou funkcí (handlerem) a volitelnými spouštěči.
src/logic-functions/createPostCard.logic-function.ts
Dostupné typy spouštěčů:
  • httpRoute: Zpřístupní vaši funkci na HTTP cestě a metodě pod koncovým bodem /s/:
např. path: '/post-card/create' je volatelné na https://your-twenty-server.com/s/post-card/create
  • cron: Spouští vaši funkci podle plánu pomocí výrazu CRON.
  • databaseEvent: Spouští se při událostech životního cyklu objektů v pracovním prostoru. Když je operace události updated, lze konkrétní sledovaná pole určit v poli updatedFields. Pokud zůstane nedefinované nebo prázdné, spustí funkci jakákoli aktualizace.
např. person.updated, *.created, company.*
Funkci můžete také spustit ručně pomocí CLI:
Logy můžete sledovat pomocí:

Payload spouštěče trasy

Když spouštěč typu route vyvolá vaši logickou funkci, ta obdrží objekt RoutePayload, který odpovídá AWS HTTP API v2 formátu. Importujte typ RoutePayload z twenty-sdk:
Typ RoutePayload má následující strukturu:

forwardedRequestHeaders

Ve výchozím nastavení se záhlaví HTTP z příchozích požadavků z bezpečnostních důvodů do vaší logické funkce ne předávají. Chcete-li zpřístupnit konkrétní záhlaví, výslovně je uveďte v poli forwardedRequestHeaders:
Ve vašem handleru k přeposlaným záhlavím přistupujte takto:
Názvy záhlaví jsou normalizovány na malá písmena. Přistupujte k nim pomocí klíčů s malými písmeny (například event.headers['content-type']).

Zpřístupnění funkce jako nástroje

Logické funkce lze zpřístupnit jako nástroje pro agenty AI a pracovní postupy. Když je funkce označena jako nástroj, stane se dohledatelnou funkcemi AI produktu Twenty a lze ji použít v automatizacích pracovních postupů.Chcete-li označit logickou funkci jako nástroj, nastavte isTool: true:
src/logic-functions/enrich-company.logic-function.ts
Hlavní body:
  • Můžete kombinovat isTool se spouštěči — funkce může být zároveň nástrojem (volatelným agenty AI) a současně se spouštět událostmi.
  • toolInputSchema (volitelné): Objekt JSON Schema, který popisuje parametry, jež vaše funkce přijímá. Schéma se určuje automaticky ze statické analýzy zdrojového kódu, ale můžete ho nastavit i explicitně:
Napište kvalitní description. Agenti AI se spoléhají na pole funkce description při rozhodování, kdy nástroj použít. Buďte konkrétní ohledně toho, co nástroj dělá a kdy se má volat.
Postinstalační funkce je logická funkce, která se spustí automaticky, jakmile je instalace vaší aplikace v pracovním prostoru dokončena. Server ji provede poté, co byla synchronizována metadata aplikace a vygenerován klient SDK, takže je pracovní prostor plně připraven k použití a nové schéma je zavedeno. Mezi typické případy použití patří naplnění výchozími daty, vytvoření počátečních záznamů, konfigurace nastavení pracovního prostoru nebo zřizování prostředků ve službách třetích stran.
src/logic-functions/post-install.ts
Postinstalační funkci můžete také kdykoli spustit ručně pomocí CLI:
Hlavní body:
  • Postinstalační funkce používají definePostInstallLogicFunction() — specializovanou variantu, která vynechává nastavení spouštěčů (cronTriggerSettings, databaseEventTriggerSettings, httpRouteTriggerSettings, isTool).
  • Obslužná funkce obdrží InstallPayload s { previousVersion?: string; newVersion: string }newVersion je verze, která se instaluje, a previousVersion je verze, která byla nainstalována dříve (nebo undefined při čisté instalaci). Tyto hodnoty použijte k rozlišení čistých instalací od aktualizací a ke spuštění migrační logiky specifické pro verzi.
  • Kdy se hook spouští: ve výchozím nastavení pouze při čistých instalacích. Předejte shouldRunOnVersionUpgrade: true, pokud chcete, aby se spouštěl i při aktualizaci aplikace z předchozí verze. Pokud je vynechán, příznak má výchozí hodnotu false a při aktualizacích se hook přeskočí.
  • Model provádění — ve výchozím nastavení asynchronní, synchronní volitelně: příznak shouldRunSynchronously určuje jak se spouští post-install.
    • shouldRunSynchronously: false (výchozí) — hook je zařazen do fronty zpráv s retryLimit: 3 a běží asynchronně ve workeru. Odezva instalace se vrátí hned po zařazení úlohy do fronty, takže pomalá nebo chybující obslužná funkce neblokuje volajícího. Worker se pokusí o opakování až třikrát. Použijte pro dlouho běžící úlohy — plnění velkých datových sad, volání pomalých externích API, zřizování externích prostředků, cokoli, co by mohlo přesáhnout rozumné časové okno HTTP odezvy.
    • shouldRunSynchronously: true — hook se provádí inline během instalačního procesu (stejný vykonavatel jako pre-install). Instalační požadavek blokuje, dokud obslužná funkce nedokončí, a pokud vyvolá výjimku, volající instalace obdrží POST_INSTALL_ERROR. Žádné automatické opakování. Použijte pro rychlé úlohy, které se musí dokončit před odpovědí — například vrácení validační chyby uživateli nebo rychlé nastavení, na kterém bude klient záviset ihned po návratu volání instalace. Mějte na paměti, že v době, kdy se spustí post-install, už byla migrace metadat aplikována, takže selhání v synchronním režimu změny schématu nevrací zpět — pouze odhalí chybu.
  • Ujistěte se, že vaše obslužná funkce je idempotentní. V asynchronním režimu se může fronta pokusit až třikrát; v obou režimech se může hook znovu spustit při aktualizacích, pokud je shouldRunOnVersionUpgrade: true.
  • Proměnné prostředí APPLICATION_ID, APP_ACCESS_TOKEN a API_URL jsou dostupné uvnitř obslužné funkce (stejně jako u jakékoli jiné logické funkce), takže můžete volat Twenty API s aplikačním přístupovým tokenem omezeným na vaši aplikaci.
  • Na jednu aplikaci je povolena pouze jedna postinstalační funkce. Sestavení manifestu skončí chybou, pokud je zjištěna více než jedna.
  • Atributy funkce universalIdentifier, shouldRunOnVersionUpgrade a shouldRunSynchronously jsou během buildu automaticky připojeny k manifestu aplikace do pole postInstallLogicFunction — není potřeba je uvádět v defineApplication().
  • Výchozí časový limit je nastaven na 300 sekund (5 minut), aby umožnil delší úlohy nastavení, jako je naplnění daty.
  • Nespouští se v režimu dev: když je aplikace registrována lokálně (pomocí yarn twenty dev), server zcela přeskočí instalační tok a synchronizuje soubory přímo prostřednictvím sledovače CLI — takže se post-install v režimu dev nikdy nespustí bez ohledu na shouldRunSynchronously. Použijte yarn twenty exec --postInstall k ručnímu spuštění nad běžícím pracovním prostorem.
Funkce pre-install je logická funkce, která se během instalace spouští automaticky, před aplikováním migrace metadat pracovního prostoru. Má stejný tvar payloadu jako post-install (InstallPayload), ale je zařazena dříve v instalačním toku, aby mohla připravit stav, na němž nadcházející migrace závisí — typické použití zahrnuje zálohování dat, ověření kompatibility s novým schématem nebo archivaci záznamů, které se chystají přeuspořádat nebo odstranit.
src/logic-functions/pre-install.ts
Předinstalační funkci můžete také kdykoli spustit ručně pomocí CLI:
Hlavní body:
  • Funkce pre-install používají definePreInstallLogicFunction() — stejné specializované nastavení jako u post-install, pouze připojené k jiné fázi životního cyklu.
  • Obě obslužné funkce pre- i post-install přijímají stejný typ InstallPayload: { previousVersion?: string; newVersion: string }. Importujte jej jednou a znovu použijte pro oba hooky.
  • Kdy se hook spouští: umístěn těsně před migrací metadat pracovního prostoru (synchronizeFromManifest). Před spuštěním server provede čistě aditivní “zjednodušenou synchronizaci”, která v metadatech pracovního prostoru zaregistruje pre-install funkci nové verze — ničeho dalšího se nedotkne — a poté ji spustí. Protože tato synchronizace je pouze aditivní, objekty, pole a data předchozí verze zůstávají při spuštění vaší obslužné funkce zachována: můžete bezpečně číst a zálohovat stav před migrací.
  • Model provádění: pre-install se provádí synchronně a blokuje instalaci. Pokud obslužná funkce vyvolá výjimku, instalace se přeruší ještě před aplikováním jakýchkoli změn schématu — pracovní prostor zůstane na předchozí verzi v konzistentním stavu. Je to záměrné: pre-install je vaše poslední šance odmítnout rizikovou aktualizaci.
  • Stejně jako u post-install je na jednu aplikaci povolena pouze jedna funkce pre-install. Během buildu je automaticky připojena k manifestu aplikace pod preInstallLogicFunction.
  • Nespouští se v režimu dev: stejně jako u post-install — u lokálně registrovaných aplikací je instalační tok zcela přeskočen, takže se pre-install pod yarn twenty dev nikdy nespustí. Použijte yarn twenty exec --preInstall k ručnímu spuštění.
Oba hooky jsou součástí téhož instalačního toku a přijímají stejný InstallPayload. Rozdíl je v tom, kdy se spouštějí vzhledem k migraci metadat pracovního prostoru, a to určuje, jakých dat se mohou bezpečně dotýkat.
Pre-install je vždy synchronní (blokuje instalaci a může ji přerušit). Post-install je ve výchozím nastavení asynchronní — zařazen do workeru s automatickými pokusy o opakování — ale může přejít na synchronní provádění pomocí shouldRunSynchronously: true. Viz accordion definePostInstallLogicFunction výše, kdy použít jednotlivé režimy.Použijte post-install pro cokoli, co vyžaduje existenci nového schématu. To je běžný případ:
  • Plnění výchozími daty (vytváření počátečních záznamů, výchozích pohledů, demo obsahu) vůči nově přidaným objektům a polím.
  • Registrace webhooků u služeb třetích stran poté, co má aplikace své přihlašovací údaje.
  • Volání vlastního API k dokončení nastavení, které závisí na synchronizovaných metadatech.
  • Idempotentní logika “zajisti, že to existuje”, která má při každé aktualizaci uvést stav do souladu — kombinujte s shouldRunOnVersionUpgrade: true.
Příklad — po instalaci naplňte výchozí záznam PostCard:
src/logic-functions/post-install.ts
Použijte pre-install, pokud by migrace jinak zničila nebo poškodila existující data. Protože pre-install běží proti předchozímu schématu a jeho selhání vrací aktualizaci zpět, je to správné místo pro cokoli rizikového:
  • Zálohování dat, která se chystají odstranit nebo přeuspořádat — např. odstraňujete pole ve verzi v2 a potřebujete jeho hodnoty zkopírovat do jiného pole nebo je před spuštěním migrace exportovat do úložiště.
  • Archivace záznamů, které by nové omezení zneplatnilo — např. pole se stává NOT NULL a je třeba nejprve smazat nebo opravit řádky s hodnotami null.
  • Ověření kompatibility a odmítnutí aktualizace, pokud nelze aktuální data čistě migrovat — vyhoďte výjimku z obslužné funkce a instalace se ukončí bez provedených změn. Je to bezpečnější, než zjistit nekompatibilitu uprostřed migrace.
  • Přejmenování nebo změna klíčů dat před změnou schématu, která by ztratila vazby.
Příklad — archivujte záznamy před destruktivní migrací:
src/logic-functions/pre-install.ts
Zlaté pravidlo:
Pokud si nejste jisti, výchozí volbou je post-install. Po pre-install sáhněte pouze tehdy, když je samotná migrace destruktivní a potřebujete zachytit předchozí stav, než zmizí.

Typovaní klienti API (twenty-client-sdk)

Balíček twenty-client-sdk poskytuje dva typované klienty GraphQL pro práci s Twenty API z vašich logických funkcí a frontendových komponent.
CoreApiClient je hlavní klient pro dotazování a mutace dat pracovního prostoru. Generuje se z vašeho schématu pracovního prostoru během yarn twenty dev nebo yarn twenty build, takže je plně typovaný tak, aby odpovídal vašim objektům a polím.
Klient používá syntaxi výběrové sady (selection-set): předáním true zahrnete pole, pro argumenty použijte __args a pro relace vnořujte objekty. Získáte plné automatické doplňování a kontrolu typů založené na schématu vašeho pracovního prostoru.
CoreApiClient je generován při vývoji/sestavení. Pokud jej použijete bez předchozího spuštění yarn twenty dev nebo yarn twenty build, vyvolá chybu. Generování probíhá automaticky — CLI prozkoumá GraphQL schéma vašeho pracovního prostoru a vygeneruje typovaného klienta pomocí @genql/cli.

Použití CoreSchema pro anotace typů

CoreSchema poskytuje typy TypeScriptu odpovídající objektům vašeho pracovního prostoru — hodí se pro typování stavu komponent nebo parametrů funkcí:
MetadataApiClient je dodáván předem sestavený v rámci SDK (není vyžadováno žádné generování). Odesílá dotazy na endpoint /metadata pro konfiguraci pracovního prostoru, aplikace a nahrávání souborů.

Nahrávání souborů

MetadataApiClient obsahuje metodu uploadFile pro připojování souborů k polím typu souboru:
Hlavní body:
  • Používá universalIdentifier pole (nikoli jeho ID specifické pro pracovní prostor), takže váš kód pro nahrávání funguje v jakémkoli pracovním prostoru, kde je vaše aplikace nainstalována.
  • Vrácená hodnota url je podepsaná adresa URL, kterou můžete použít k přístupu k nahranému souboru.
Když váš kód běží na Twenty (logické funkce nebo frontendové komponenty), platforma vloží přihlašovací údaje jako proměnné prostředí:
  • TWENTY_API_URL — Základní URL Twenty API
  • TWENTY_APP_ACCESS_TOKEN — krátkodobý klíč s rozsahem omezeným na výchozí roli funkce vaší aplikace
Není nutné je předávat klientům — čtou je automaticky z process.env. Oprávnění API klíče jsou určena rolí uvedenou v defaultRoleUniversalIdentifier ve vašem application-config.ts.