Automatisierungsregeln
Eine Automatisierungsregel ist eine in normaler Sprache formulierte Anweisung, die ein Sprachmodell ausführt, sobald ein bestimmtes Ereignis eintritt. Das Modell erhält den Regeltext zusammen mit dem Ereignis, etwa einer eingegangenen E-Mail, und entscheidet selbst, welche der erlaubten Werkzeuge es aufruft: Es kann zum Beispiel Entitäten suchen, Dokumente lesen, Werte extrahieren, Attributwerte setzen oder das Team benachrichtigen. Anders als ein Regelset, das feste Bedingungen auswertet, beschreibt eine Automatisierungsregel ein Vorgehen in Prosa. Alles, was der Text offen lässt, bleibt Interpretationssache des Modells.
Die Regeln finden Sie im Administrationsbereich in der Kategorie „Automatisierung“ unter der Kachel „Automatisierungsregeln“. Dieselbe Kategorie enthält die Kachel „Extraktoren“ (siehe Extraktoren).
Hauptschalter
Section titled “Hauptschalter”Automatisierungsregeln laufen nur, wenn der Hauptschalter für die Automatisierung eingeschaltet ist. Er ist standardmäßig ausgeschaltet und wird in den Einstellungen in der Gruppe „Automatisierung“ unter dem Schlüssel automation.enabled geführt. Solange er aus ist, zeigt die Regelübersicht einen entsprechenden Hinweis. Regeln lassen sich auch dann anlegen und bearbeiten, es läuft aber keine.
Regelübersicht
Section titled “Regelübersicht”Die Übersicht listet alle Regeln mit folgenden Spalten:
- Name mit der Beschreibung der Regel.
- Auslöser: das Ereignis, auf das die Regel reagiert.
- Modus: Probelauf, Vorschlagen oder Ausführen, jeweils farblich abgesetzt.
- Erlaubte Werkzeuge: „Alle Werkzeuge“, wenn die Regel jedes Werkzeug verwenden darf. Andernfalls steht dort die Zahl der ausgewählten Werkzeuge im Verhältnis zu allen verfügbaren, zum Beispiel „5 von 25“.
- Status: Aktiv, Inaktiv oder Archiviert.
- Läufe: die Anzahl bisheriger Läufe. Ein Klick öffnet die Laufliste, gefiltert auf diese Regel.
- Aktionen: Aktivieren oder Deaktivieren (nur bei nicht archivierten Regeln), Bearbeiten, Archivieren oder Wiederherstellen sowie Löschen (nur bei Regeln ohne Läufe).
Über die Schaltfläche „Läufe“ oberhalb der Tabelle gelangen Sie zur Liste aller Läufe. Warten Läufe auf eine Freigabe, steht deren Anzahl in Klammern auf der Schaltfläche. „Automatisierungsregel erstellen“ öffnet den Dialog zum Anlegen einer neuen Regel.
Eine archivierte Regel läuft nicht mehr. Beim Wiederherstellen kommt sie inaktiv zurück und muss bewusst wieder aktiviert werden. Löschen lässt sich eine Regel nur, solange sie noch keine Läufe hat. Hat eine Regel bereits Läufe, wird die Aktion „Löschen“ nicht angeboten. Um eine solche Regel außer Betrieb zu nehmen, archivieren Sie sie. Die Historie ihrer Läufe bleibt dabei erhalten.
Regel anlegen
Section titled “Regel anlegen”Der Dialog enthält folgende Felder:
- Name (Pflicht): die Bezeichnung der Regel.
- Beschreibung (optional): erläutert den Zweck.
- Auslöser (Pflicht): das Ereignis, das der Regel einen Lauf anbietet.
- Regel (Pflicht): die Anweisung als normaler Text. Benennen Sie, worauf zu achten ist, was geändert werden darf und wo die Grenzen liegen.
- Vorfilter (optional): ein Ausdruck, der vorab entscheidet, ob die Regel für ein Ereignis überhaupt anspringt.
- Erlaubte Werkzeuge: die Aktionen, die die Regel ausführen darf. Zur Wahl stehen „Alle Werkzeuge“ und „Ausgewählte Werkzeuge“ (siehe Erlaubte Werkzeuge). Bei einer neuen Regel ist zunächst „Alle Werkzeuge“ eingestellt.
- Modus (Pflicht): was mit schreibenden Aktionen geschieht.
- Maximale Aktionen pro Lauf (Pflicht, 1 bis 100, Standard 8): Obergrenze für die Aktionen eines einzelnen Laufs. Es gilt der kleinere Wert aus diesem Feld und der globalen Obergrenze der Einstellungen.
- Aktiv: schaltet die Regel ein. Eine neue Regel ist zunächst nicht aktiv.
Zu mehreren Feldern zeigt ein Hilfesymbol eine Kurzerklärung an.
Auslöser
Section titled “Auslöser”Im Feld „Auslöser“ stehen mehrere Ereignisse zur Wahl. Derzeit lösen zwei tatsächlich aus:
- Eingehende Mail: Eine E-Mail wurde empfangen und gespeichert.
- Dokumenttyp erkannt: Nach dem Hochladen einer Datei wurde deren Dokumenttyp automatisch erkannt.
Weitere Auslöser sind bereits aufgeführt, aber mit dem Zusatz „noch nicht angebunden, eine Regel darauf läuft nie“ gekennzeichnet, ebenso in der Regelübersicht. Dazu gehören „Extraktion abgeschlossen“, „Attributwert geändert“, „Entität angelegt“, „Zeitgesteuert“ und „Von Hand gestartet“. Sie sind für künftige Versionen vorgesehen. Eine Regel auf einen solchen Auslöser anzulegen ist möglich, sie wird aber nie ausgeführt.
Vorfilter
Section titled “Vorfilter”Ein Vorfilter ist ein optionaler Ausdruck, der vor jedem Lauf prüft, ob die Regel für das Ereignis anspringen soll. Ist das Feld leer, gilt die Regel für jedes Ereignis des gewählten Auslösers. Nur bei einem Treffer startet ein Lauf, bei allen anderen Ereignissen entstehen weder ein Lauf noch Kosten für das Sprachmodell.
Der Ausdruck wird über die Variable trigger ausgewertet. Je nach Auslöser stehen darin folgende Angaben zur Verfügung:
| Angabe | Bedeutung |
|---|---|
kind, entity_id, entity_type |
Art des Ereignisses sowie Kennung und Typ der betroffenen Entität |
message_id |
Kennung der E-Mail (Eingehende Mail) |
mail_contact |
Absender der E-Mail |
subject |
Betreff der E-Mail |
recipients |
alle Empfängeradressen in Kleinbuchstaben (An, Kopie, Zustellkopfzeilen) |
mailbox |
das Postfach, in dem die E-Mail eingegangen ist |
attachment_names, attachment_mimetypes, attachment_document_type_ids |
Namen, Dateitypen und Dokumenttypen der Anhänge |
file_id, file_name, file_mimetype, document_type_id |
Angaben zur Datei (Dokumenttyp erkannt) |
Fehlende Texte gelten als leerer Text, fehlende Listen als leere Liste, damit ein Ausdruck nicht an einer fehlenden Angabe scheitert. Über recipients kann eine Regel beispielsweise nur auf E-Mails reagieren, die an eine bestimmte Adresse gerichtet sind, etwa eine eigene Adresse für Zertifikate, die im selben Postfach landet. Auch Kopie- und Weiterleitungsadressen zählen mit. Die Syntax der Ausdrücke ist auf der Seite Ausdrücke beschrieben, die Angaben zu trigger stehen im Abschnitt zum Vorfilter auf der Seite Kontexte für Ausdrücke.
Vorfilter testen
Section titled “Vorfilter testen”Mit „Vorfilter testen“ prüfen Sie den Ausdruck gegen einen echten Datensatz. Geben Sie dazu die Kennung eines passenden Datensatzes ein, bei einer eingehenden Mail also die Kennung der Nachricht. Die Schaltfläche ist aktiv, sobald Ausdruck und Kennung eingetragen sind. Das Ergebnis lautet „Die Regel würde laufen“ oder „Die Regel würde nicht laufen“ und wird zusammen mit den Angaben angezeigt, gegen die ausgewertet wurde. Der Test schreibt nichts und startet keinen Lauf.
Der Modus bestimmt, was mit schreibenden Aktionen geschieht. Lesende Werkzeuge laufen in jedem Modus.
| Modus | Wirkung |
|---|---|
| Probelauf | Schreibende Aktionen werden nur aufgezeichnet, aber nicht ausgeführt. |
| Vorschlagen | Der Lauf hält vor jeder schreibenden Aktion an und wartet auf die Freigabe durch einen Administrator. |
| Ausführen | Die Regel schreibt ohne Rückfrage. |
Eine neue Regel steht zunächst im Probelauf. Beobachten Sie in den Läufen, was die Regel tun würde, und schalten Sie erst auf Vorschlagen oder Ausführen um, wenn die aufgezeichneten Aktionen passen. Ein Lauf behält den Modus, den die Regel bei seinem Start hatte, auch wenn die Regel später geändert wird.
Erlaubte Werkzeuge
Section titled “Erlaubte Werkzeuge”Werkzeuge sind die einzelnen Aktionen, die das Modell im Rahmen einer Regel aufrufen darf. Im Feld „Erlaubte Werkzeuge“ stehen zwei Einstellungen zur Verfügung:
- Alle Werkzeuge: Die Regel darf jedes Werkzeug verwenden, auch solche, die in späteren Versionen hinzukommen. Bei einer neuen Regel ist diese Einstellung vorgewählt. Im Probelauf, dem Standardmodus einer neuen Regel, schreibt die Regel damit nichts.
- Ausgewählte Werkzeuge: Sie wählen die Werkzeuge per Mehrfachauswahl aus. Die Regel kann ausschließlich die ausgewählten Werkzeuge aufrufen. Ist kein Werkzeug ausgewählt, kann sie gar nichts tun. Später hinzukommende Werkzeuge muss jemand ausdrücklich in die Auswahl aufnehmen, sonst kann die Regel sie nicht verwenden.
Regeln, die bereits vor dieser Einstellung mit einer Werkzeugliste gespeichert wurden, behalten ihre Liste. Die Regelübersicht zeigt in der Spalte „Erlaubte Werkzeuge“, welche Einstellung eine Regel hat.
Schreibende Werkzeuge tragen in der Auswahl den Zusatz „schreibt Daten“. Nehmen Sie diese bewusst und einzeln in die Liste auf. Mit „Alle Werkzeuge“ erlaubt eine Regel sie automatisch.
Die Werkzeuge werden in der Auswahl mit ihrem technischen Namen aufgeführt:
| Werkzeug | Wirkung | Schreibend |
|---|---|---|
search_entities |
Entitäten eines Typs anhand von Bedingungen auf Attributwerten suchen, sortieren und zählen, auch unterhalb oder oberhalb einer Entität | nein |
get_entity |
Eine Entität mit Status (erfüllt, inaktiv, archiviert), Tags und ihren direkten Eltern und Kindern abrufen (siehe Beispiele) | nein |
get_entity_attributes |
Die Attributwerte einer Entität lesen | nein |
list_attribute_definitions |
Die verfügbaren Attribute auflisten | nein |
list_extractors |
Die konfigurierten Extraktoren auflisten | nein |
read_document |
Den Text einer Datei abschnittsweise lesen | nein |
run_extractor |
Einen konfigurierten Extraktor auf eine Datei anwenden | nein |
extract_document_fields |
Frei beschriebene Felder aus einer Datei auslesen, ohne einen Extraktor zu benötigen | nein |
list_extractor_results |
Bereits vorhandene Extraktionsergebnisse einer Datei abrufen | nein |
apply_extractor_results |
Extrahierte Werte einer Datei in die zugeordneten Attribute übernehmen | ja |
set_attribute_value |
Einen Attributwert setzen | ja |
update_message |
Eine E-Mail einer Entität zuordnen oder markieren | ja |
notify_internal |
Das Team intern benachrichtigen | ja |
get_entity_checklists |
Die Checklisten einer Entität mit allen Punkten, deren Stand, Einreichungen und den zugehörigen Anforderungsnachrichten abrufen | nein |
list_messages |
Die Nachrichten einer Entität auflisten, neueste zuerst, auch Anforderungen, die für ihre Punkte versendet wurden | nein |
get_message |
Eine Nachricht vollständig lesen: angeforderte Punkte, Anhänge und Text | nein |
list_notes |
Die Notizen einer Entität sowie ihrer Punkte, Einreichungen und Nachrichten auflisten | nein |
list_entity_files |
Die Dateien einer Entität auflisten, auch die an ihren Punkten eingereichten | nein |
get_entity_history |
Den Verlauf (Protokoll) einer Entität seitenweise lesen, neueste Einträge zuerst | nein |
list_checklist_definitions |
Die konfigurierten Checklisten mit ihren Punkten sowie alle Themen auflisten | nein |
get_entity_test_plans |
Die Prüfpläne einer Entität abrufen: Soll- und Ist-Werte je Punkt, Ergebnis, blockierende Entität, Freigaben | nein |
get_form_submission |
Die Antworten eines Formulars lesen, das an einem Checklistenpunkt eingereicht wurde | nein |
search_messages |
Nachrichten über alle Entitäten nach Status, Art, Datum, Kontakt oder Betreff suchen | nein |
list_jobs |
Hintergrundaufträge (Jobs) nach Art, Status oder Datum auflisten, mit Laufzeit und Fehler | nein |
search_docs |
Die Certiflow-Dokumentation durchsuchen | nein |
read_docs |
Eine Seite oder einen Abschnitt der Certiflow-Dokumentation lesen | nein |
Kommen in einer neuen Version Werkzeuge hinzu, stehen sie Regeln mit „Alle Werkzeuge“ sofort zur Verfügung. Bei „Ausgewählte Werkzeuge“ müssen sie ausdrücklich in die Auswahl aufgenommen werden.
Mehr über eine Entität lesen
Section titled “Mehr über eine Entität lesen”Mit den lesenden Werkzeugen für Entitäten kann eine Regel nicht nur Attributwerte, sondern auch das Umfeld einer Entität berücksichtigen:
- Checklisten:
get_entity_checklistszeigt jeden Checklistenpunkt mit seinem Stand, etwa erfüllt, eingereicht und noch nicht geprüft, in Karenzzeit, abgelehnt, abgelaufen oder noch nie angefordert. Daran erkennt die Regel auch Punkte, für die bisher keine Anforderung versendet wurde. - Nachrichten:
list_messages,get_messageundsearch_messagesliefern Betreff, Status und Text von Nachrichten, bei Bedarf über alle Entitäten hinweg. Zugangslinks zum Lieferantenportal werden dabei entfernt, bevor der Text an das Sprachmodell geht. - Notizen und Dateien:
list_notesundlist_entity_fileszeigen, was an der Entität, ihren Punkten, Einreichungen und Nachrichten notiert wurde und welche Dateien vorliegen. - Verlauf:
get_entity_historyliefert die Einträge des Protokolls zu einer Entität, bei vielen Einträgen seitenweise. - Prüfpläne:
get_entity_test_planszeigt je Punkt Soll- und Ist-Wert, ob der Punkt besteht, welche Entität ihn blockiert und welche Freigaben vorliegen. - Formulareinreichungen:
get_form_submissionliefert die Antworten eines an einem Checklistenpunkt eingereichten Formulars. - Hintergrundaufträge:
list_jobsist für den Betrieb gedacht und zeigt Aufträge samt Fehlern.
Die Ergebnisse enthalten das aktuelle Datum und, wo es für eine Entscheidung zählt, den Abstand zu heute in Tagen, etwa bis zum Ablauf eines Zertifikats. Entitäten, Nachrichten, Dateien und Checklistenpunkte, die ein Ergebnis nennt, kommen mit Name und Link in die Anwendung, sodass die Regel sie in ihrer Zusammenfassung angeben kann. Listen sind begrenzt und weisen darauf hin, wenn es weitere Einträge gibt. Die Rohfassung von E-Mails, Zugangsdaten und Konfigurationswerte erhält das Sprachmodell nicht.
Mit search_docs und read_docs kann eine Regel in der Certiflow-Dokumentation nachschlagen, etwa wie eine Funktion gedacht ist oder was eine Statusfarbe bedeutet. Die Dokumentation ist deutschsprachig und kann älter sein als die laufende Version. Weichen Dokumentation und Daten voneinander ab, gelten die Daten.
Welche Entitätstypen, Regelsätze, Checklisten, Prüfpläne und Themen es in Ihrer Installation gibt, ist dem Sprachmodell bereits bekannt. Installationsspezifische Hinweise, die es zusätzlich benötigt, werden bei der Einrichtung festgelegt, wenden Sie sich dazu an den Support.
Dokumente lesen und Werte extrahieren
Section titled “Dokumente lesen und Werte extrahieren”Eine Regel erhält keinen Dokumenttext vorab. Sie sieht die E-Mail mit ihrem Text und eine Liste aller Anhänge mit Kennung, Name, Typ, Größe und der Angabe, ob die Datei passwortgeschützt ist. Diese Liste steht vor dem Mailtext und wird daher nicht verdrängt. Passt nicht alles in den verfügbaren Platz, haben die Kennungen Vorrang, und nicht aufgeführte Anhänge werden ausdrücklich gezählt.
Den Inhalt eines Dokuments liest die Regel bei Bedarf selbst. Dafür stehen drei Wege zur Verfügung:
read_documentliest den Text abschnittsweise.run_extractorführt einen konfigurierten Extraktor aus.extract_document_fieldsliest frei beschriebene Felder (höchstens 20 je Aufruf) aus, ohne dass ein Extraktor angelegt sein muss.
Erreichbar sind nur die Dateien des auslösenden Ereignisses, also die Datei selbst, die Anhänge der E-Mail und die Dateien der zugehörigen Entität. Passwortgeschützte Dateien werden abgewiesen, sie müssen zuvor entschlüsselt werden. Fehlender Inhalt im Kontext bedeutet nicht, dass ein Dokument nichts Relevantes enthält: Die Regel benötigt die passenden Werkzeuge in ihrer Liste.
Die Ergebnisse von run_extractor werden nur im Modus Ausführen an der Datei gespeichert. Im Probelauf und beim Vorschlagen gehen die Werte nur an das Modell, und frühere Ergebnisse der Datei bleiben unberührt. Das hat eine wichtige Folge: Werte, die eine Regel im selben Lauf mit run_extractor gewonnen hat, kann sie nur im Modus Ausführen mit apply_extractor_results übernehmen. In den anderen Modi liegen für die Übernahme keine neuen Ergebnisse an der Datei vor. Mit extract_document_fields gelesene Werte werden nie gespeichert und erscheinen nicht unter „Extrahierte Daten“. Lesende Werkzeuge laufen auch im Probelauf und verursachen dort dieselben Kosten wie im Modus Ausführen. Sie benötigen im Modus Vorschlagen keine Freigabe, müssen aber in der Werkzeugliste der Regel enthalten sein.
Um an der Datei gespeicherte Extraktionsergebnisse in Attribute zu übernehmen, nutzt die Regel apply_extractor_results, ganz oder für ausgewählte Felder. Das Werkzeug muss in der Liste der Regel erlaubt sein, und die Datei muss einer Entität gehören. Ein Mailanhang gehört erst nach der Zuordnung der E-Mail zu einer Entität dazu. Die Schreibrechte werden je Attribut geprüft, und Werte in einer abweichenden Einheit werden übersprungen.
Werte schreiben
Section titled “Werte schreiben”Mit set_attribute_value setzt eine Regel einen Attributwert. Standardmäßig ersetzt sie den aktuellen Wert, im Modus „Anhängen“ bleibt der Bestand erhalten und der neue Wert kommt hinzu. Attribute, für die mehrere Werte vorgesehen sind (Einstellung „Mehrere Werte“ am Attribut), erlauben nur das Anhängen, ein Ersetzen wird abgelehnt. Schreibt eine Regel denselben Wert erneut, etwa weil eine E-Mail doppelt zugestellt wurde, ändert sich nichts. Beim Anhängen wird ein Wert, der inhaltlich gleich, aber anders formuliert ist, dagegen als zusätzlicher Wert hinzugefügt. Attribute, die Benutzer nicht beschreiben dürfen (Benutzerschreibmodus „Niemals“, typisch für aus dem ERP-System übernommene Werte), lehnt das Werkzeug ab.
Von einer Regel geschriebene Werte tragen die Herkunft „Aus Automatisierungsregel“. Übernimmt eine Regel Extraktionsergebnisse mit apply_extractor_results, erscheint im Protokoll der Eintrag „Extraktor-Ergebnisse übernommen“ mit dem Initiator „System“. Welche Aktionen eine Regel im Einzelnen ausgeführt hat, zeigt die Detailseite des jeweiligen Laufs.
Jedes Ereignis, das den Vorfilter passiert, startet einen Lauf. Die Seite „Läufe“ listet alle Läufe, die neuesten zuerst. Sie lassen sich nach Regel, Status und Modus filtern. Die Spalten lauten Automatisierungsregel, Status, Modus, Bezogen auf (Nachricht, Datei oder Entität mit Kennung), Aktionen (Anzahl), Tokens ein / aus und Gestartet.
Ein Lauf hat einen der folgenden Status:
| Status | Bedeutung |
|---|---|
| Läuft | Das Sprachmodell bearbeitet das Ereignis. |
| Wartet auf Freigabe | Im Modus Vorschlagen wartet der Lauf auf Entscheidungen zu vorgeschlagenen Aktionen. |
| Erfolgreich | Der Lauf ist abgeschlossen. Schlug dabei ein Teil der Aktionen fehl, steht der Status in Orange mit Fehlerangabe. |
| Fehlgeschlagen | Der Lauf wurde mit einem Fehler beendet. Das gilt auch, wenn alle Aktionen fehlschlugen oder abgelehnt wurden. |
| Traf nicht zu | Kein Fehler: Das Modell hat entschieden, dass die Regel für das Ereignis nicht passt, und kein Werkzeug aufgerufen. Ebenso endet ein Lauf, wenn beim Start der Hauptschalter aus oder die Regel inaktiv oder archiviert war. |
Die Detailseite eines Laufs zeigt Regelname und Regeltext, Status, Modus, Auslöser, Start und Ende, das verwendete Modell mit seiner Laufzeit, die Zusammenfassung des Modells, eventuelle Fehler und das auslösende Ereignis. Der Tokenverbrauch ist nach Art aufgeschlüsselt (Eingabe ohne Cache, Cache geschrieben, Cache gelesen, Ausgabe). Darunter steht jede Aktion mit ihren Argumenten und ihrem Ergebnis sowie der Kennzeichnung Ausgeführt, Genehmigt, Abgelehnt oder Nicht ausgeführt und, wenn zutreffend, dem Hinweis „Entschieden von“.
Freigabe im Modus Vorschlagen
Section titled “Freigabe im Modus Vorschlagen”Ein Lauf im Status „Wartet auf Freigabe“ zeigt die vorgeschlagenen Aktionen. Bis zu Ihrer Entscheidung wurde nichts ausgeführt. Entscheiden Sie jede Aktion einzeln mit „Genehmigen“ oder „Ablehnen“:
- Bei einer Ablehnung ist eine Begründung Pflicht, bei einer Genehmigung ist sie optional.
- Die Begründung geht wörtlich an das Modell, das sie für den weiteren Verlauf berücksichtigen kann.
Erst wenn alle Aktionen entschieden sind, lässt sich „Lauf fortsetzen“ anklicken. Der Lauf führt dann die genehmigten Aktionen aus und kann anschließend die nächste schreibende Aktion vorschlagen und erneut anhalten. Vor dem Fortsetzen prüft Certiflow, ob der Hauptschalter eingeschaltet und die Regel aktiv und nicht archiviert ist. Wurde ein Werkzeug während der Pause aus der Liste der Regel entfernt, schlägt die zugehörige Aktion trotz Genehmigung fehl. Jede genehmigte Aktion zählt auf „Maximale Aktionen pro Lauf“ an.
Eine Freigabe verfällt nach einer einstellbaren Frist, standardmäßig nach 168 Stunden (eine Woche). Der Wert 0 schaltet den Ablauf ab. Die Frist beginnt bei jedem erneuten Anhalten neu. Nach Ablauf wird der Lauf als fehlgeschlagen geschlossen und lässt sich nicht mehr fortsetzen. Bereits getroffene Entscheidungen bleiben sichtbar, wurden aber nie ausgeführt.
Grenzen und Einstellungen
Section titled “Grenzen und Einstellungen”Die Grenzen eines Laufs legen Sie in den Einstellungen in der Gruppe „Automatisierung“ fest:
| Schlüssel | Standard | Wirkung |
|---|---|---|
automation.max_tool_calls |
60 | Obergrenze für die Aktionen eines Laufs über alle Regeln hinweg. Das Limit einer einzelnen Regel kann sie nicht überschreiten. |
automation.max_context_chars |
40000 Zeichen | So viel Kontext, etwa Mailtext, erhält das Modell. Längerer Kontext wird abgeschnitten. |
automation.max_document_read_chars |
40000 Zeichen | So viel Dokumenttext darf ein Lauf insgesamt lesen. 0 schaltet das Lesen von Dokumenten ab. |
automation.max_output_tokens |
8192 Tokens | So viel darf das Modell je Schritt eines Laufs erzeugen. Ein abgeschnittener Schritt beendet den Lauf. |
automation.extraction_timeout_secs |
300 Sekunden | Dauert eine von einer Regel gestartete Extraktion länger, schlägt sie fehl. |
automation.confirmation_ttl_hours |
168 Stunden | Freigabefrist, siehe Freigabe. |
Fehlt die Anbindung an das Sprachmodell, schlagen Läufe mit entsprechender Begründung fehl. Die Anbindung wird bei der Einrichtung festgelegt, wenden Sie sich bei Fragen an den Support.
Sicherheit
Section titled “Sicherheit”Eine Regel arbeitet auf Text, den andere verfasst haben, etwa dem Inhalt einer E-Mail. Ein Absender kann versuchen, durch geschickte Formulierungen das Modell zu einer unerwünschten Aktion zu bewegen. Begrenzt wird ein solcher Versuch nur durch die Liste der erlaubten Werkzeuge, nicht durch die Entität, auf der die E-Mail gelandet ist. Nehmen Sie daher, vor allem bei Regeln im Modus Ausführen, nur die Werkzeuge in die Liste auf, die die Regel tatsächlich braucht, und wählen Sie dafür „Ausgewählte Werkzeuge“. Auch die lesenden Werkzeuge für Nachrichten, Notizen und Dateinamen liefern Text, den andere verfasst haben. Das Sprachmodell behandelt ihn als Daten und nicht als Anweisung, ein Restrisiko bleibt aber bestehen.
Beispiele
Section titled “Beispiele”Zertifikat per E-Mail einem Produkt zuordnen. Lieferanten senden Zertifikate an eine eigene Zertifikatsadresse, die im selben Postfach landet. Eine Regel mit dem Auslöser „Eingehende Mail“ und einem Vorfilter auf diese Empfängeradresse sucht das passende Produkt, ordnet die E-Mail ihm zu, liest den Anhang mit einem Extraktor aus und übernimmt die Werte in die Attribute des Produkts. Sie erhält die Werkzeuge search_entities, list_extractors, run_extractor, update_message und apply_extractor_results. Die Regel beginnt im Probelauf. Erst wenn die aufgezeichneten Aktionen über längere Zeit passen, wird sie auf Ausführen umgestellt, denn nur in diesem Modus speichert run_extractor die Werte, die apply_extractor_results anschließend übernimmt.
Zu welcher Bezugsquelle gehört diese Charge? Mit get_entity ruft die Regel eine Entität samt ihren direkten Eltern und Kindern ab, etwa zu einer Charge die übergeordnete Bezugsquelle oder zu einer Bezugsquelle die zugehörigen Chargen. Es wird nur eine Ebene geliefert, keine ganze Hierarchie. Die Ausgabe lässt sich auf einen Entitätstyp einschränken und umfasst standardmäßig 25, höchstens 100 Einträge je Richtung, mit Gesamtzahl und einem Hinweis, falls gekürzt wurde. Wie jedes andere Werkzeug muss get_entity dafür in die Werkzeugliste der Regel aufgenommen werden. Zu den Beziehungen zwischen Entitätstypen siehe Entitäten.