Entwicklung benutzerdefinierter Marketing-Automatisierung in Xperience von Kentico

Die drei Erweiterungsverträge

Die Automation-Customization-API umfasst jetzt den vollständigen Prozesslebenszyklus mit drei verfügbaren Erweiterungspunkten:

• Benutzerdefinierter Auslöser – erbt von AutomationTrigger, AutomationTrigger<TData> oder AutomationTrigger<TData, TProperties>, registriert über RegisterAutomationTrigger<TTrigger>
• Benutzerdefinierte Aktion – erbt von AutomationAction oder AutomationAction<TProperties>, registriert über RegisterAutomationAction<TAction>
• Benutzerdefinierte Bedingung – erbt von AutomationCondition oder AutomationCondition<TProperties>, registriert über RegisterAutomationCondition<TCondition>

Alle drei Komponententypen befinden sich in CMS.Automation. Ihre Registrierungsattribute verleihen der Komponente eine stabile Kennung und einen Anzeigenamen mit optionalen Symbol- und Beschreibungsmetadaten für den Builder. Konfigurierbare Varianten verwenden eine Eigenschaftenklasse, die mit Administrationsattributen für Bearbeitungskomponenten in Xperience dekoriert ist.

Die Unterscheidung zwischen den Verträgen ist bewusst. Trigger reagieren auf Ereignisse und entscheiden, ob ein Prozess gestartet wird. Aktionen sind für Nebeneffekte verantwortlich. Bedingungen lesen den Kontext und liefern eine Verzweigungsentscheidung zurück. Die Trennung dieser Verantwortlichkeiten erleichtert das Testen und Nachvollziehen eines Automatisierungsprozesses.

Implementierung eines benutzerdefinierten Auslösers

Ein benutzerdefinierter Auslöser startet Automatisierungen aus Anwendungscode. Typische Einsatzorte sind Objekt-Ereignishandler, Checkout-Controller, Webhook-Endpunkte, Integrationsdienste oder geplante Aufgaben.

Ein Auslöser kann so einfach sein wie eine Klasse, die von AutomationTriggererbt. Nützlichere Integrationen können typisierte Ereignisdaten über IAutomationTriggerData übertragen und prozessspezifische Konfigurationen über IAutomationTriggerPropertiesanbieten.

Das Beispiel in den folgenden Abschnitten folgt einer verbundenen Kundenreise:

1. Ein bekannter Besucher sieht sich die Detailseite eines Fahrzeugmodells an.
2. Der Besucher absolviert später eine Probefahrt bei einem Händler, der die Information im CRM erfasst.
3. Ein CRM-Webhook löst einen benutzerdefinierten Xperience-Auslöser für den zugeordneten Kontakt aus.
4. Die eingebaute Kontakt hat in den letzten X Tagen eine Seite besucht Bedingung überprüft, ob der Kontakt kürzlich dieses Modell online angesehen hat.
5. Eine benutzerdefinierte Bedingung prüft, ob die CRM-Gelegenheit noch für ein persönliches Angebot geeignet ist.
6. Der wahre Zweig führt eine benutzerdefinierte Aktion aus, die das Angebot erstellt. Jeder falsche Zweig kann den Prozess ohne Angebot beenden.

Der Auslöser überträgt die CRM-Aktivitäts- und Fahrzeugkennungen in den Prozess. Sein konfigurierbarer Modellcode ermöglicht Marketern, separate Prozesse für unterschiedliche Fahrzeugkampagnen zu erstellen.

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: "Probefahrt abgeschlossen",
    Description = "Startet einen Nachfolgeprozess, nachdem ein Autohaus eine Probefahrt erfasst hat.",
    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 = "Fahrzeugmodellcode", 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));
    }
}

Die Properties-Klasse wird in der Automation Builder zur UI-Konfiguration des Triggers. Verschiedene Prozesse können denselben Trigger für unterschiedliche Modelle verwenden. Wenn das CRM-Event eintrifft, bewertet Xperience jeden Prozess, der den Trigger nutzt, anhand des gespeicherten Modellcodes und der Wiederholungseinstellungen dieses Prozesses.

Trigger-Klassen müssen zustandslos sein. Xperience erstellt eine Trigger-Instanz und verwendet sie für alle Bewertungen wieder, daher gehören dispatch-spezifische Daten in die typisierte Trigger-Nutzlast und nicht in Instanzfelder.

Die Definition eines Triggers ist nur die Hälfte der Implementierung. Das CRM-Webhooks muss den Kontaktbezeichner auf ein Xperience  ContactInfo Objekt abbilden und den Trigger auslösen. Der Resolver im folgenden Beispiel ist anwendungsspezifisch; er kapselt die Identitätszuordnung ein, die hergestellt wurde, als der Besucher ein bekannter Kontakt wurde.

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);

Trigger-Daten werden mit dem Prozesszustand serialisiert, sodass nachgeschaltete benutzerdefinierte Schritte sie über AutomationProcessContext.GetTriggerData<T>() abrufen können, ohne eine weitere CRM-Abfrage durchführen zu müssen, nur um herauszufinden, welche Probefahrt den Prozess gestartet hat. Die Nutzlast enthält Identifikatoren und Ereignisdetails statt des Namens, der E-Mail-Adresse oder eines kopierten CRM-Datensatzes des Besuchers.

„FireTrigger“ fügt die Anfrage in die Warteschlange ein und gibt sofort zurück, bevor die Verarbeitung beginnt. Die begrenzte In-Memory-Warteschlange wird von benutzerdefinierten Triggern und dem eingebauten Formular-Trigger gemeinsam genutzt. Wenn die Warteschlange voll ist, werden weitere Trigger verworfen und Xperience protokolliert eine Warnung. Implementierungen mit hohem Volumen sollten dieses Verhalten überwachen und  CMSAutomationTriggerQueueCapacity nur anpassen, nachdem sie ihren Prozessdurchsatz verstanden haben. Ein geschäftskritisches CRM-Ereignis sollte zuerst in einem dauerhaften Integrationspostfach gespeichert und dedupliziert werden, wobei ein Hintergrunddienst den Trigger auslöst. Für geplante Aufgaben, die Trigger für Kontaktgruppen auslösen, empfiehlt Kentico, dies höchstens einmal täglich zu tun, um Überlastungen zu vermeiden.

Implementierung einer benutzerdefinierten Bedingung

Eine benutzerdefinierte Bedingung fügt projektspezifische Verzweigungen hinzu. Sie kann den Kontakt, Trigger-Daten, gespeicherte Prozessdaten oder Informationen aus externen Systemen prüfen und dann `true` oder `false` zurückgeben.

Der kürzliche Webseitenbesuch erfordert keinen benutzerdefinierten Code. Im Automation Builder platzieren Sie die integrierte  Contact has visited a page in the last X days Bedingung nach dem Trigger und konfigurieren sie mit der Fahrzeugdetailseite und Kampagnenzeitraum. Jeder modell-spezifische Prozess koppelt diese Seitenauswahl mit demselben Modellcode, der im Trigger eingestellt ist.

Die benutzerdefinierte Bedingung sollte eine Frage beantworten, die Xperience nicht allein mit den Kontaktdaten bewerten kann. Das folgende Beispiel fragt das CRM, ob die mit der Probefahrt verbundene Chance weiterhin für ein persönliches Angebot geeignet ist. Der anwendungsspezifische Dienst kann Regeln zentralisieren, wie z. B. die Anforderung einer offenen Chance und das Ausschließen eines abgeschlossenen Verkaufs oder eines bereits ausgestellten Angebots.

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 erlaubt persönliches Angebot",
    Description = "Prüft, ob die CRM-Gelegenheit für ein Angebot berechtigt ist.",
    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,
                "Konnte die Berechtigung für das Angebot für die CRM-Aktivität {CrmActivityId} nicht bewerten.",
                triggerData.CrmActivityId);

            return false;
        }
    }
}

Registrierte Bedingungen erscheinen unter Bedingungen neben der integrierten regelbasierten Bedingung. Verbinden Sie den wahren Pfad der integrierten Seitenbesuch-Bedingung mit CRM erlaubt persönliches Angebot, verbinden Sie dann dessen wahren Pfad mit der Erstelle Probefahrt-Angebot Aktion, die im nächsten Abschnitt implementiert wird. Beide falschen Pfade sollten einen sicheren Fallback wie das Ende des Prozesses verwenden. Ein nicht verfügbares CRM folgt dem falschen Zweig, sodass dieser Zweig niemals ein Angebot senden oder eine andere auf Berechtigung sensible Aktion ausführen darf.

Bedingungen sollten schreibgeschützt und idempotent sein, da Xperience sie möglicherweise mehr als einmal auswertet. Aktualisieren Sie keine Kontakte, speichern Sie keine Prozessdaten oder lösen Sie keine externen Seiteneffekte aus Evaluate. Wenn eine Entscheidung Mutation oder aufwändige Vorbereitung erfordert, führen Sie diese in einer vorherigen Aktion aus, speichern Sie das Ergebnis als Prozessdaten und lassen Sie die Bedingung dieses Ergebnis lesen.

Implementierung einer benutzerdefinierten Aktion

Eine benutzerdefinierte Aktion führt Arbeit aus, wenn ein Kontakt seinen Schritt erreicht. Dies ist der richtige Erweiterungspunkt für Nebenwirkungen wie die Synchronisierung eines CRM-Datensatzes, die Anreicherung von Kontaktdaten, das Versenden einer internen Benachrichtigung, das Aufrufen einer externen API oder das Veröffentlichen eines Analyseereignisses.

Die Aktion überschreibt Execute und erhält einen AutomationProcessContext. Der Kontext stellt den verarbeiteten Kontakt, Prozess-Metadaten, Trigger-Daten und typisierte Daten bereit, die von früheren Schritten gespeichert wurden.

Die folgende Aktion gehört zum echten Zweig der benutzerdefinierten CRM-Bedingung, die im vorherigen Abschnitt nach der eingebauten Seitenbesuchsbedingung gezeigt wurde. Sie erstellt ein persönliches Angebot über einen anwendungsspezifischen Angebotsdienst, indem die CRM-Aktivität und das Fahrzeugmodell verwendet werden, die vom Trigger übermittelt werden. Marketingfachleute wählen die Angebotsvorlage und die Gültigkeitsdauer, ohne den externen Dienst selbst konfigurieren zu müssen.

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: "Angebot zur Probefahrt erstellen",
    Description = "Erstellt ein persönliches Angebot nach einer relevanten Probefahrt.",
    IconName = Icons.StarFull)]

namespace Acme.Automation;

public sealed class TestDriveOfferProperties : IAutomationActionProperties
{
    [TextInputComponent(Label = "Angebotsvorlagen-Code", Order = 10)]
    [RequiredValidationRule]
    public string OfferTemplateCode { get; set; } = string.Empty;

    [NumberInputComponent(Label = "Gültig für Tage", 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(
                "Testfahrten-Auslöserdaten fehlen im Prozess {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);
    }
}

Entwurf konfigurierbarer Komponenten

Eigenschaften verwandeln eine vom Entwickler definierte Komponente in ein wiederverwendbares Builder-Werkzeug. Implementieren Sie das entsprechende Interface—IAutomationTriggerProperties, IAutomationActionProperties oder IAutomationConditionProperties—und dekorieren Sie öffentliche Getter/Setter mit Bearbeitungskomponenten aus Kentico.Xperience.Admin.Base.FormAnnotations.

Das Eigenschaftsmodell unterstützt Text-, Zahlen-, Kontrollkästchen-, Datums- und Zeit-, Rich-Text- und Dropdown-Eingaben. Es unterstützt auch Validierungsregeln, bedingte Sichtbarkeit, Kategorien, Standardwerte und dynamische Dropdown-Optionen. Das bedeutet, eine einzige Integrationskomponente kann mehrere Prozesse ohne harte Kampagneneinstellungen bedienen.

Die Registrierungsmetadaten verdienen dieselbe Sorgfalt. Anzeigenamen sollten die Operation in Geschäftssprache beschreiben. Beschreibungen sollten erklären, wann die Komponente verwendet wird, und Symbole sollten ähnliche Typen leichter erkennbar machen. Version 31.7.0 verbessert auch den Auswahldialog für Schritttypen, indem Schritttypen in Schritte und Bedingungen gruppiert, die Suche gepinnt und eingebaute mit benutzerdefinierten Typen zusammen aufgelistet werden.

KentiCopilot-Unterstützung für Automatisierungskomponenten

Das KentiCopilot "kentico-digital-experience" Plugin wurde veröffentlicht, um die  KI-gestützte Implementierung von Marketing-Automatisierungskomponenten zu unterstützen. Seine anfängliche benutzerdefinierte Aktionsfähigkeit wurde am 31. Juli durch Fähigkeiten für die Entwicklung benutzerdefinierter Trigger und Bedingungen ergänzt. Gemeinsam führen sie Codierassistenten durch dieselben Verträge, die oben beschrieben sind: Auswahl der richtigen Basisklasse, Definition optionaler Eigenschaften und typisierter Daten, Registrierung der Komponente und Verknüpfung der Trigger-Dispatch im Anwendungscode.

Quellcode und Nutzungsinformationen des Plugins sind im KentiCopilot Digital Experience Plugin verfügbar.

Migration benutzerdefinierter Aktivitäts-Workarounds

Bestehende Prozesse müssen nicht sofort neu geschrieben werden. Beginnen Sie damit, echte Marketingaktivitäten von  technischen Relay-Nachrichten zu unterscheiden. Ein Ereignis, das in die Aktivitätshistorie eines Kontakts gehört, kann eine benutzerdefinierte Aktivität bleiben. Xperience empfiehlt benutzerdefinierte Aktivitäten auch dann, wenn ein Automatisierungsprozess absichtlich einen anderen startet, da die Aktivität eine nützliche Dokumentation dieses Übergangs liefert.

Das Zusammenführen von Zweigen ist ein Beispiel: Getrennte Zweige können dieselbe benutzerdefinierte Aktivität protokollieren, die einen gemeinsamen Folgeprozess startet und diesen Zweigen eine  gemeinsame Fortsetzung bietet.

Für technische Relay-Aktivitäten folgt das Migrationsziel direkt aus der Verantwortung. Eine Aktivität, die vom Anwendungscode nur zur Automatisierungsinitialisierung protokolliert wird, wird zu einem  benutzerdefinierten Trigger und einem Dispatcher-Aufruf. Eine Aktivität, die von einem Prozess nur zum Aufruf einer Integration protokolliert wird, wird zu einer  benutzerdefinierten Aktion , die von einem injizierten Service unterstützt wird. Eine Entscheidung, die zuvor außerhalb des Prozesses getroffen wurde, wird zu einer benutzerdefinierten Bedingung, die optional typisierte Daten liest, die von einer früheren Aktion vorbereitet wurden.

Ein direktes Modell für benutzerdefinierte Automatisierung

Das Refresh Juli 2026 bietet Xperience-Projekten ein direktes Programmiermodell für benutzerdefinierte Automatisierung. Anwendungsevents lösen typisierte Trigger aus. Aktionen führen Seiteneffekte durch injizierte Services aus. Bedingungen treffen schreibgeschützte Entscheidungen aus dem Prozesskontext. Registrierungs- und Eigenschaftsklassen verwandeln jede Implementierung in eine  konfigurierbare Automation Builder-Komponente.

Entwickler müssen nicht mehr jede Integration durch benutzerdefiniertes Aktivitäts-Logging erzwingen, und Marketer müssen keine generischen Schritte interpretieren, die von versteckten Handlern unterstützt werden. Code und Prozess verwenden jetzt dieselben drei Konzepte: Start bei diesem Ereignis, Führe diese Operation aus und Wähle den nächsten Pfad.