Vývoj vlastních marketingových automatizací v Xperience by Kentico

Aktualizace Xperience od Kentico z 28. července 2026, vydaná jako verze 31.7.0, dokončuje model rozšiřitelnosti marketingové automatizace pro vývojáře. Vlastní akce už dříve umožňovaly přidávat do procesu vlastní operace. Nová verze přidává vlastní triggery a vlastní podmínky, čímž vývojářům dává plnohodnotné rozšiřovací body pro to, jak proces začíná, co dělá a jak se větví.

Každé rozšíření se v Automation Builderu objeví jako nativní komponenta. Vývojáři chování implementují a zaregistrují v aplikaci Xperience, zatímco marketéři výsledný trigger, akci nebo podmínku umístí do procesu a nastaví jeho vystavené vlastnosti. Vizuální podoba procesu tak konečně může popisovat skutečný byznysový workflow, místo aby se spoléhala na technické vlastní aktivity a kód běžící mimo dohled.

Kentico zároveň v repozitáři KentiCopilot vydalo plugin „kentico-digital-experience“ pro vývoj automatizačních komponent s pomocí AI. Aktualizace z 31. července přidala k existující dovednosti pro vlastní akce také dovednosti pro triggery a podmínky.

Limity náhradních řešení postavených na vlastních aktivitách

Než plnohodnotné vlastní komponenty pokryly celý proces, musely velkou část integrační zátěže nést vlastní aktivity. Byly užitečné v tom, že aplikace mohla zalogovat událost specifickou pro daný projekt a automatizační proces na ni mohl reagovat. Aktivita se ale často stala spíše technickou zprávou než smysluplným záznamem o chování kontaktu.

Spuštění procesu z vlastní aplikační události vyžadovalo, aby aplikace zalogovala vlastní aktivitu a marketér vybral vestavěný trigger Custom activity. Před zavedením vlastních akcí bylo spuštění vlastní logiky uprostřed procesu podobně nepřímé: proces zalogoval další vlastní aktivitu, samostatný kód ji odposlouchával a teprve tento posluchač provedl skutečnou operaci. Vlastní akce druhé náhradní řešení odstranily, ale vlastní spuštění procesu zůstávalo až do verze 31.7.0 založené na aktivitách.

Diagram procesu proto nevyprávěl celý příběh. Krok pojmenovaný „Log custom activity“ mohl ve skutečnosti znamenat „Synchronizuj tento kontakt s CRM“ nebo „Vyžádej aktualizaci věrnostního statusu“. Editoři museli vědět, které aktivity jsou technické signály, jaký externí kód je obsluhuje a zda tento kód proběhl úspěšně. Neshoda v kódovém názvu aktivity nebo v její konfiguraci navíc mohla spojení mezi procesem a jeho skrytou implementací rozbít.

Největší mezerou byla rozhodnutí specifická pro projekt. Vlastní aktivity dokázaly volat aplikační kód, ale nemohly určit, kterou cestou se má kontakt vydat. Kontroly zahrnující CRM, fakturační systém, věrnostní službu nebo skórovací model tak zůstávaly mimo Automation Builder. Vlastní podmínky tato rozhodnutí přinášejí přímo do procesu jako opakovaně použitelné a konfigurovatelné kroky. Mohou vyhodnotit kontakt, data z triggeru nebo externí službu a vybrat cestu. Pokud rozhodnutí závisí na dřívější práci, může vlastní akce uložit typovaná data do kontextu procesu a následující podmínka je načíst a zvolit odpovídající cestu. Rozhodnutí tak zůstává viditelné pro marketéry a byznysová logika v aplikačním kódu.

Červencová aktualizace tyto oklikové postupy odstraňuje. Vlastní aktivity zůstávají cenné tam, kde je událost skutečně součástí historie aktivit kontaktu, už ale nemusí sloužit jako univerzální přenosový mechanismus pro veškeré vlastní chování automatizace.

Tři rozšiřovací kontrakty

API pro přizpůsobení automatizace nyní pokrývá celý životní cyklus procesu a nabízí tři rozšiřovací body:

• Vlastní trigger – dědí od AutomationTrigger, AutomationTrigger<TData> nebo AutomationTrigger<TData, TProperties>, registrovaný přes RegisterAutomationTrigger<TTrigger>
• Vlastní akce – dědí od AutomationAction nebo AutomationAction<TProperties>, registrovaná přes RegisterAutomationAction<TAction>
• Vlastní podmínka – dědí od AutomationCondition nebo AutomationCondition<TProperties>, registrovaná přes RegisterAutomationCondition<TCondition>

Všechny tři typy komponent žijí v CMS.Automation. Jejich registrační atributy dávají komponentě stabilní identifikátor a zobrazovaný název, volitelně také metadata s ikonou a popisem pro builder. Konfigurovatelné varianty používají třídu vlastností opatřenou atributy editačních komponent administrace Xperience.

Rozdělení kontraktů je záměrné. Triggery reagují na události a rozhodují, zda se proces spustí. Akce vlastní vedlejší efekty. Podmínky čtou kontext a vracejí rozhodnutí o větvi. Oddělení těchto odpovědností usnadňuje testování automatizačního procesu i uvažování o něm.

Implementace vlastního triggeru

Vlastní trigger spouští automatizaci z aplikačního kódu. Typickými místy pro jeho odeslání jsou handler objektových událostí, kontroler pokladny, webhookový endpoint, integrační služba nebo naplánovaná úloha.

Trigger může být tak jednoduchý jako třída dědící z AutomationTrigger. Užitečnější integrace mohou přenášet typovaná data události přes IAutomationTriggerData a vystavit konfiguraci pro jednotlivé procesy přes IAutomationTriggerProperties.

Příklad použitý v následujících sekcích sleduje jednu souvislou zákaznickou cestu:

1. Známý návštěvník si prohlédne detailní stránku modelu vozu.
2. Návštěvník později absolvuje testovací jízdu u prodejce a ten ji zaznamená do CRM.
3. Webhook z CRM vyvolá vlastní trigger v Xperience pro namapovaný kontakt.
4. Vestavěná podmínka Contact has visited a page in the last X days ověří, zda si kontakt daný model nedávno prohlížel online.
5. Vlastní podmínka zkontroluje, zda je příležitost v CRM stále způsobilá pro osobní nabídku.
6. Větev true spustí vlastní akci, která nabídku vytvoří. Kterákoli z větví false může proces ukončit bez jejího vytvoření.

Trigger přenáší do procesu identifikátory CRM aktivity a vozu. Díky konfigurovatelnému kódu modelu mohou marketéři vytvářet samostatné procesy pro různé kampaně na jednotlivé modely.

using System;
using System.Threading;
using System.Threading.Tasks;

using CMS.Automation;

using Kentico.Xperience.Admin.Base;
using Kentico.Xperience.Admin.Base.FormAnnotations;

using Acme.Automation;

[assembly: RegisterAutomationTrigger<TestDriveCompletedTrigger>(
    identifier: TestDriveCompletedTrigger.IDENTIFIER,
    displayName: "Jízda na zkoušku dokončena",
    Description = "Spustí následný proces po zaznamenání jízdy na zkoušku u prodejce.",
    IconName = Icons.UserCheckbox)]

namespace Acme.Automation;

public sealed class TestDriveCompletedData : IAutomationTriggerData
{
    public string Identifier => "Acme.TestDriveCompletedData";

    public string CrmActivityId { get; init; } = string.Empty;

    public string VehicleModelCode { get; init; } = string.Empty;

    public string DealerCode { get; init; } = string.Empty;

    public DateTimeOffset CompletedAt { get; init; }
}

public sealed class TestDriveTriggerProperties : IAutomationTriggerProperties
{
    [TextInputComponent(Label = "Kód modelu vozidla", Order = 10)]
    [RequiredValidationRule]
    public string VehicleModelCode { get; set; } = string.Empty;
}

public sealed class TestDriveCompletedTrigger
    : AutomationTrigger<TestDriveCompletedData, TestDriveTriggerProperties>
{
    public const string IDENTIFIER = "Acme.TestDriveCompletedTrigger";

    public override Task<bool> Evaluate(
        AutomationTriggerContext context,
        TestDriveTriggerProperties properties,
        TestDriveCompletedData triggerData,
        CancellationToken cancellationToken)
    {
        return Task.FromResult(string.Equals(
            triggerData.VehicleModelCode,
            properties.VehicleModelCode,
            StringComparison.OrdinalIgnoreCase));
    }
}

Třída vlastností se v Automation Builderu stane konfiguračním rozhraním triggeru. Různé procesy mohou stejný trigger používat pro různé modely. Když dorazí událost z CRM, Xperience vyhodnotí každý proces, který trigger používá, vůči kódu modelu uloženému v daném procesu a vůči jeho nastavení opakování.

Třídy triggerů musí být bezstavové. Xperience vytvoří jednu instanci triggeru a znovu ji používá při všech vyhodnoceních, takže data specifická pro konkrétní odeslání patří do typovaného payloadu triggeru, nikoli do instančních polí.

Definice triggeru je jen polovina implementace. Webhook z CRM musí namapovat svůj identifikátor kontaktu na objekt ContactInfo v Xperience a trigger odeslat. Resolver v následujícím příkladu je specifický pro danou aplikaci; zapouzdřuje mapování identit vzniklé ve chvíli, kdy se z návštěvníka stal známý kontakt.

using System;
using System.Threading;
using System.Threading.Tasks;

using CMS.Automation;
using CMS.ContactManagement;

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

using Acme.Automation;

[ApiController]
[Authorize(AuthenticationSchemes = "CrmWebhook")]
[Route("integrations/crm/test-drives")]
public sealed class TestDriveWebhookController(
    ICrmContactResolver contactResolver,
    IAutomationTriggerDispatcher triggerDispatcher)
    : ControllerBase
{
    [HttpPost("completed")]
    public async Task<IActionResult> Completed(
        TestDriveCompletedWebhook webhook,
        CancellationToken cancellationToken)
    {
        if (string.IsNullOrWhiteSpace(webhook.CrmContactId)
            || string.IsNullOrWhiteSpace(webhook.CrmActivityId)
            || string.IsNullOrWhiteSpace(webhook.VehicleModelCode)
            || string.IsNullOrWhiteSpace(webhook.DealerCode)
            || webhook.CompletedAt == default
            || webhook.CompletedAt > DateTimeOffset.UtcNow.AddMinutes(5))
        {
            return BadRequest();
        }

        ContactInfo? contact = await contactResolver.FindContact(
            webhook.CrmContactId,
            cancellationToken);

        if (contact is null)
        {
            return NotFound();
        }

        await triggerDispatcher.FireTrigger<TestDriveCompletedTrigger>(
            new AutomationTriggerDispatch(
                contact,
                new TestDriveCompletedData
                {
                    CrmActivityId = webhook.CrmActivityId,
                    VehicleModelCode = webhook.VehicleModelCode,
                    DealerCode = webhook.DealerCode,
                    CompletedAt = webhook.CompletedAt.ToUniversalTime()
                }),
            cancellationToken);

        return Accepted();
    }
}

public sealed record TestDriveCompletedWebhook(
    string CrmContactId,
    string CrmActivityId,
    string VehicleModelCode,
    string DealerCode,
    DateTimeOffset CompletedAt);

Data triggeru se serializují spolu se stavem procesu, takže navazující vlastní kroky je mohou získat přes AutomationProcessContext.GetTriggerData<T>() bez dalšího dotazu do CRM jen kvůli zjištění, která testovací jízda proces spustila. Payload obsahuje identifikátory a fakta o události, nikoli jméno návštěvníka, e-mailovou adresu nebo zkopírovaný záznam z CRM.

Metoda FireTrigger zařadí požadavek do fronty a vrátí se okamžitě, ještě před zahájením zpracování. Omezenou frontu v paměti sdílejí vlastní triggery s vestavěným triggerem Form. Pokud se fronta zaplní, další triggery se zahodí a Xperience zaloguje varování. Implementace s vysokým objemem provozu by měly toto chování sledovat a hodnotu CMSAutomationTriggerQueueCapacity upravovat až poté, co porozumí propustnosti svých procesů. Byznysově kritickou událost z CRM je vhodné nejprve trvale uložit a deduplikovat v odolné integrační schránce a trigger odesílat z pracovního procesu na pozadí. U naplánovaných úloh, které spouštějí triggery pro skupiny kontaktů, doporučuje Kentico spouštění nejvýše jednou denně, aby nedocházelo k nadměrné zátěži.

Implementace vlastní podmínky

Vlastní podmínka přidává větvení specifické pro projekt. Může prozkoumat kontakt, data triggeru, uložená data procesu nebo informace z externího systému a poté vrátit true, nebo false.

Nedávná návštěva webu vlastní kód nevyžaduje. V Automation Builderu umístěte za trigger vestavěnou podmínku Contact has visited a page in the last X days a nastavte v ní detailní stránku vozu a časové okno kampaně. Každý proces pro konkrétní model pak páruje tento výběr stránky se stejným kódem modelu nastaveným na triggeru.

Vlastní podmínka by měla odpovídat na otázku, kterou Xperience nedokáže vyhodnotit z vlastních dat o kontaktu. Následující příklad se ptá CRM, zda příležitost spojená s testovací jízdou stále splňuje podmínky pro osobní nabídku. Služba specifická pro aplikaci může centralizovat pravidla, jako je požadavek na otevřenou příležitost a vyloučení dokončeného prodeje nebo již vydané nabídky.

using System.Threading;
using System.Threading.Tasks;

using CMS.Automation;

using Kentico.Xperience.Admin.Base;

using Microsoft.Extensions.Logging;

using Acme.Automation;

[assembly: RegisterAutomationCondition<CrmAllowsPersonalOfferCondition>(
    identifier: CrmAllowsPersonalOfferCondition.IDENTIFIER,
    displayName: "CRM umožňuje osobní nabídku",
    Description = "Kontroluje, zda je CRM příležitost způsobilá pro nabídku.",
    IconName = Icons.CheckCircle)]

namespace Acme.Automation;

public sealed class CrmAllowsPersonalOfferCondition(
    ICrmTestDriveService crmTestDriveService,
    ILogger<CrmAllowsPersonalOfferCondition> logger)
    : AutomationCondition
{
    public const string IDENTIFIER = "Acme.CrmAllowsPersonalOffer";

    public override async Task<bool> Evaluate(
        AutomationProcessContext context,
        CancellationToken cancellationToken)
    {
        TestDriveCompletedData triggerData =
            await context.GetTriggerData<TestDriveCompletedData>(cancellationToken);

        if (triggerData is null)
        {
            return false;
        }

        try
        {
            return await crmTestDriveService.IsEligibleForPersonalOffer(
                triggerData.CrmActivityId,
                cancellationToken);
        }
        catch (CrmUnavailableException exception)
        {
            logger.LogError(
                exception,
                "Nepodařilo se vyhodnotit způsobilost nabídky pro CRM aktivitu {CrmActivityId}.",
                triggerData.CrmActivityId);

            return false;
        }
    }
}

Zaregistrované podmínky se objeví v sekci Conditions vedle vestavěné podmínky Rule-based. Připojte větev true vestavěné podmínky pro návštěvu stránky k podmínce CRM allows personal offer a její větev true poté k akci Create test-drive offer, kterou implementujeme v následující sekci. Obě větve false by měly vést k bezpečnému záložnímu řešení, například k ukončení procesu. Nedostupné CRM se vydá větví false, takže tato větev nesmí nikdy odeslat nabídku ani provést jinou akci citlivou na způsobilost.

Podmínky by měly být pouze pro čtení a idempotentní, protože je Xperience může vyhodnotit i vícekrát. Z metody Evaluate neaktualizujte kontakty, neukládejte data procesu ani nevyvolávejte externí vedlejší efekty. Pokud rozhodnutí vyžaduje změnu dat nebo nákladnou přípravu, proveďte ji v předcházející akci, výsledek uložte jako data procesu a nechte podmínku tento výsledek pouze přečíst.

Implementace vlastní akce

Vlastní akce vykoná práci ve chvíli, kdy kontakt dorazí k jejímu kroku. Je to správný rozšiřovací bod pro vedlejší efekty, jako je synchronizace záznamu v CRM, obohacení dat kontaktu, odeslání interní notifikace, volání externího API nebo publikování analytické události.

Akce přepisuje metodu Execute a dostává AutomationProcessContext. Kontext poskytuje zpracovávaný kontakt, metadata procesu, data triggeru a typovaná data uložená dřívějšími kroky.

Následující akce patří na větev true vlastní CRM podmínky z předchozí sekce, tedy až za vestavěnou podmínku návštěvy stránky. Vytváří osobní nabídku prostřednictvím aplikační služby pro nabídky, a to na základě CRM aktivity a modelu vozu, které nese trigger. Marketéři volí šablonu nabídky a dobu platnosti, aniž by museli konfigurovat samotnou externí službu.

using System.Threading;
using System.Threading.Tasks;

using CMS.Automation;
using CMS.ContactManagement;
using Kentico.Xperience.Admin.Base;
using Kentico.Xperience.Admin.Base.FormAnnotations;
using Microsoft.Extensions.Logging;

using Acme.Automation;

[assembly: RegisterAutomationAction<CreateTestDriveOfferAction>(
    identifier: CreateTestDriveOfferAction.IDENTIFIER,
    displayName: "Vytvořit nabídku na testovací jízdu",
    Description = "Vytváří osobní nabídku po relevantní testovací jízdě.",
    IconName = Icons.StarFull)]

namespace Acme.Automation;

public sealed class TestDriveOfferProperties : IAutomationActionProperties
{
    [TextInputComponent(Label = "Kód šablony nabídky", Order = 10)]
    [RequiredValidationRule]
    public string OfferTemplateCode { get; set; } = string.Empty;

    [NumberInputComponent(Label = "Platné po dny", Order = 20)]
    [MinimumIntegerValueValidationRule(1)]
    [MaximumIntegerValueValidationRule(60)]
    public int ValidForDays { get; set; } = 14;
}

public sealed class CreateTestDriveOfferAction(
    ITestDriveOfferService offerService,
    ILogger<CreateTestDriveOfferAction> logger)
    : AutomationAction<TestDriveOfferProperties>
{
    public const string IDENTIFIER = "Acme.CreateTestDriveOffer";

    public override async Task Execute(
        TestDriveOfferProperties properties,
        AutomationProcessContext context,
        CancellationToken cancellationToken)
    {
        TestDriveCompletedData triggerData =
            await context.GetTriggerData<TestDriveCompletedData>(cancellationToken);

        if (triggerData is null)
        {
            logger.LogWarning(
                "Data spouštěče testovací jízdy chybí v procesu {ProcessName}.",
                context.Process.DisplayName);
            return;
        }

        ContactInfo contact = await context.GetProcessedObject(cancellationToken);

        await offerService.EnqueuePersonalOffer(
            contact.ContactID,
            triggerData.CrmActivityId,
            triggerData.VehicleModelCode,
            triggerData.DealerCode,
            properties.OfferTemplateCode,
            properties.ValidForDays,
            cancellationToken);
    }
}

Po registraci se komponenta objeví ve výběrovém dialogu v sekci Steps. Editor uvidí „Create test-drive offer“ a může vybrat šablonu spravovanou byznysem i dobu platnosti.
Akce mohou také připravit data pro pozdější kroky. Datovou třídu implementující IAutomationProcessData lze uložit pomocí SetProcessData a později načíst přes GetProcessData<T>. Tento vzor se hodí, když jedna akce spočítá skóre nebo získá stav, který potřebuje několik následujících podmínek. Zároveň drží podmínky bez změn dat a bez duplicitních volání integrací.

Návrh konfigurovatelných komponent

Vlastnosti mění komponentu definovanou vývojářem v opakovaně použitelný nástroj v builderu. Implementujte odpovídající rozhraní – IAutomationTriggerProperties, IAutomationActionProperties, nebo IAutomationConditionProperties – a veřejné get/set vlastnosti opatřete editačními komponentami z Kentico.Xperience.Admin.Base.FormAnnotations.

Model vlastností podporuje textové, číselné a zaškrtávací vstupy, vstupy pro datum a čas, rich-textové editory i rozbalovací seznamy. Podporuje také validační pravidla, podmíněnou viditelnost, kategorie, výchozí hodnoty a dynamické položky rozbalovacích seznamů. Jediná integrační komponenta tak může sloužit více procesům bez natvrdo zapsaných nastavení kampaně.

Stejnou péči si zaslouží registrační metadata. Zobrazované názvy by měly popisovat operaci byznysovým jazykem. Popisy by měly vysvětlit, kdy komponentu použít, a ikony by měly usnadnit orientaci mezi podobnými typy. Verze 31.7.0 navíc vylepšuje dialog Select step type – typy kroků seskupuje do sekcí Steps a Conditions, ukotvuje vyhledávání a vestavěné i vlastní typy zobrazuje pohromadě.

Podpora KentiCopilot pro automatizační komponenty

Plugin „kentico-digital-experience“ pro KentiCopilot byl vydán jako podpora implementace komponent marketingové automatizace s pomocí AI. Po jeho úvodní dovednosti pro vlastní akce následovaly 31. července dovednosti pro vývoj vlastních triggerů a podmínek. Společně provedou kódovací asistenty stejnými kontrakty, jaké popisujeme výše: výběrem správné bázové třídy, definicí volitelných vlastností a typovaných dat, registrací komponenty a zapojením odeslání triggeru do aplikačního kódu.

Zdrojový kód pluginu a informace o jeho použití najdete v pluginu KentiCopilot digital experience.

Migrace náhradních řešení s vlastními aktivitami

Existující procesy není nutné přepisovat okamžitě. Začněte tím, že odlišíte skutečné marketingové aktivity od technických přenosových zpráv. Událost, která patří do historie aktivit kontaktu, může vlastní aktivitou zůstat. Xperience doporučuje vlastní aktivity i tehdy, když jeden automatizační proces záměrně spouští jiný – aktivita totiž poskytuje užitečný záznam o tomto přechodu.

Příkladem je slučování větví: jednotlivé větve mohou zalogovat stejnou vlastní aktivitu, která spustí sdílený navazující proces a dá těmto větvím společné pokračování.

U technických přenosových aktivit vyplývá cíl migrace přímo z jejich odpovědnosti. Z aktivity, kterou aplikační kód loguje jen proto, aby spustil automatizaci, se stává vlastní trigger a volání dispatcheru. Z aktivity, kterou proces loguje jen proto, aby vyvolal integraci, se stává vlastní akce podpořená injektovanou službou. Z rozhodnutí, které se dříve přesouvalo mimo proces, se stává vlastní podmínka, případně čtoucí typovaná data připravená dřívější akcí.

Přímý model pro vlastní automatizaci

Červencová aktualizace 2026 dává projektům v Xperience přímý programovací model pro vlastní automatizaci. Aplikační události odesílají typované triggery. Akce provádějí vedlejší efekty přes injektované služby. Podmínky činí rozhodnutí pouze pro čtení na základě kontextu procesu. Registrační třídy a třídy vlastností mění každou implementaci v konfigurovatelnou komponentu Automation Builderu.

Vývojáři už nemusí protlačovat každou integraci přes logování vlastních aktivit a marketéři už nemusí luštit obecné kroky podpořené skrytými handlery. Kód i proces nyní používají stejné tři koncepty: spusť se při této události, proveď tuto operaci a zvol další cestu.