Was Sie bauen werden
Eine Automatisierung mit vier Teilen:- Einen Trigger für den Moment, der es wert ist, gemeldet zu werden
- Eine HTTP Request-Aufgabe, die JSON an Ihren Endpunkt POSTet, authentifiziert mit einem Bearer-Token
- Eine beschriebene Response, damit das, was der Endpunkt zurücksendet, zu Feldern wird
- Eine spätere Aufgabe, die eines dieser Felder verwendet
Dieses Rezept sendet Daten aus HireData heraus. Wenn Sie eigentlich die andere Richtung brauchen – ein anderes Tool sendet Daten hinein, um eine Automatisierung zu starten –, ist das stattdessen ein Custom-App-Trigger. Siehe Custom Apps und Einen Trigger einrichten.
Was Sie vorab erfragen sollten
Wer den Endpunkt besitzt, hat all das. Es vorab zu bekommen erspart eine Runde Raten:- Die URL, die aufgerufen werden soll, und die Methode, die sie erwartet
- Den Body, den sie erwartet, idealerweise als Beispiel-JSON-Payload statt als Beschreibung
- Wie sie authentifiziert. Dieses Rezept verwendet einen für diese Integration ausgestellten Bearer-Token, keinen persönlichen
- Was sie zurückgibt – sowohl wenn ein Aufruf akzeptiert als auch wenn er abgelehnt wird
- Ob es eine Test- oder Sandbox-Adresse gibt. Der Test in Schritt 7 sendet einen echten Request, Sie wollen also ein sicheres Ziel dafür
Die Automatisierung bauen
1. Auf den meldenswerten Moment triggern
Öffnen Sie den Start-Block. Wählen Sie HireData als App, dann Conversation als Objekt und Ended als Trigger. Die Automatisierung läuft jetzt einmal, jedes Mal wenn eine Konversation endet. Jeder Trigger funktioniert hier – eine abgeschlossene Formularantwort, ein aktualisierter Kandidat in Ihrem ATS. Er ändert nur, welche Felder Ihnen in Schritt 4 zum Senden zur Verfügung stehen; der Rest des Rezepts bleibt gleich.2. Die HTTP-Request-Aufgabe hinzufügen
Fügen Sie eine Aufgabe hinzu und wählen Sie HTTP Request. Sie ist sowohl unter Add als auch unter Message einsortiert, und beide Wege öffnen dieselbe Aufgabe – siehe wo Sie die Aufgabe finden. Wenn Sie beim Erfragen der Endpunkt-Details eine Spezifikation oder einen cURL-Befehl erhalten haben, klicken Sie jetzt auf Import in der Fußzeile des Drawers und lassen Sie HireData den Request ausfüllen. Die beiden Wege füllen unterschiedliche Dinge aus – prüfen Sie also was ein Import ausfüllt und gehen Sie dann die Schritte 3 bis 6 gegen das durch, was er geschrieben hat. Andernfalls füllen Sie ihn wie unten von Hand aus.3. Methode und URL festlegen
Eine neue Aufgabe hat die Methode bereits aufPOST gesetzt – genau das, was Sie wollen. Geben Sie die Adresse Ihres Endpunkts in die URL-Leiste ein:
4. Den JSON-Body aus Automatisierungsfeldern bauen
Öffnen Sie den Tab Body und fügen Sie pro Wert, den Sie senden möchten, eine Eigenschaft hinzu. Neben jedem Value sitzt eine Feldauswahl: Nutzen Sie sie, um ein Feld aus dem Run zu wählen, statt einen festen Wert einzutippen – so sendet jeder Run seine eigenen Daten. Punkte in einem Eigenschaftsnamen verschachteln ihn, ein Body wie dieser braucht also sechs Eigenschaften:
Eine Konversation gruppiert die beteiligten Personen unter Sender, Receiver und Owner – wählen Sie also von der Seite, auf der der Kandidat steht: der Sender, wenn er die Konversation gestartet hat, der Receiver, wenn Ihre Automatisierung es war. Auf der Sender-Seite richtet sich, welches Kontaktdetail ausgefüllt ist, nach dem Kanal – eine Telefonnummer bei WhatsApp, eine E-Mail-Adresse bei E-Mail.
Allgemeiner gilt: Welche Felder Sie wählen können, hängt vom Trigger ab, den Sie in Schritt 1 gewählt haben, und schließt Werte ein, die frühere Aufgaben derselben Automatisierung erzeugt haben. Was bei Ihrem Endpunkt ankommt, ist gewöhnliches JSON:
5. Mit einem Bearer-Token authentifizieren
Öffnen Sie den Tab Auth, wählen SieBearer token und fügen Sie den Token in Token ein. HireData sendet ihn als Authorization-Header bei jedem Request; im Tab Headers müssen Sie keinen Header hinzufügen.
Wenn der Endpunkt stattdessen einen Key in einem benannten Header oder Query-Parameter erwartet oder eine Client-ID und ein Secret gegen einen Token tauscht, decken die anderen Typen beides ab – siehe Authentifizierung.
6. Beschreiben, was zurückkommt
Zwei Dinge sind zu tun, bevor die Response nutzbar ist – und es ist in dieser Reihenfolge einfacher. Beginnen Sie im Tab Advanced und schreiben Sie eine Description – „Post conversation outcome” für diese Aufgabe. Sie betitelt die Aufgabe überall sonst und ist die erste Hälfte des Namens jedes Feldes, das diese Aufgabe erzeugt – sie jetzt festzulegen erspart Ihnen später das Durchlesen einer Auswahl voller umbenannter Felder. Beschreiben Sie dann im Bereich Response unterhalb der Tabs den Body, den Ihr Endpunkt zurückgibt. Angenommen, er beantwortet einen erfolgreichen Aufruf damit:id, mit dem Label „Event ID”, und eine für status, mit dem Label „Status”. Spätere Aufgaben können diese beiden jetzt namentlich auswählen:
Post conversation outcome: idPost conversation outcome: status
id zu beschreiben erspart einer späteren Aufgabe, ihn aus diesem Text herauszugraben.
Beschreiben Sie unter Error response (non-2xx), was der Endpunkt zurückgibt, wenn er einen Aufruf ablehnt – meist eine Meldung, die Sie in einem Log haben wollen. Dieser Baum lohnt sich nur, wenn Sie den Run so einstellen, dass er über einen Fehlschlag hinaus weiterläuft – siehe Festlegen, was passiert, wenn der Aufruf fehlschlägt unten.
Ein Wert, den Sie hier nicht beschreiben, ist ein Wert, den keine spätere Aufgabe namentlich herausgreifen kann. Siehe die Response beschreiben.
7. Den Request vor der Aktivierung testen
Klicken Sie auf Test in der Fußzeile und lesen Sie die Warnung, bevor Sie auf Send klicken. Der Dialog fragt nach einem Wert pro Parameter, gruppiert nach Zugehörigkeit. Der Request dieses Rezepts hat keine Pfad- oder Query-Parameter, Sie sehen also nur eine Body-Gruppe, ein Eingabefeld pro Eigenschaft aus Schritt 4. Alles, was Sie in Schritt 4 auf einen festen Wert gesetzt haben, ist bereits ausgefüllt. Die Eigenschaften, die Sie an Automatisierungsfelder gebunden haben, bleiben leer, weil diese Werte nur während eines echten Runs existieren – tippen Sie in jede davon ein plausibles Literal. Siehe die Werte ausfüllen. Klicken Sie auf Send. Sie erhalten ein Statuswort, den HTTP-Code und die Dauer des Aufrufs zurück, dazu den vollständigen Response-Body – und einen Bereich Outputs, der die Werte auflistet, die HireData mit dem in Schritt 6 gebauten Baum herausgezogen hat. Lesen Sie beides gegeneinander. Eine Eigenschaft, die Sie beschrieben haben, die aber fehlt, zeigt sich hier – und das ist der günstigste Moment, das herauszufinden.8. Einen Response-Wert in einer späteren Aufgabe verwenden
Fügen Sie nach dem HTTP Request eine Aufgabe hinzu, die etwas mit dem Zurückgekommenen tut. Add → Note ist die einfachste: Setzen SiePost conversation outcome: id in den Text der Notiz, damit die Referenz, die Ihr eigenes System generiert hat, auch in HireData festgehalten ist.
Jede spätere Aufgabe, die einen Textwert annimmt, funktioniert genauso. Das Muster ist das Entscheidende: Die Antwort des Endpunkts ist jetzt ein Datum im Run, nicht etwas, das Sie nachschlagen müssen. Siehe einen Response-Wert in einer späteren Aufgabe verwenden.
Festlegen, was passiert, wenn der Aufruf fehlschlägt
Ihr Endpunkt wird irgendwann nicht erreichbar sein. Zwei Schalter im Tab Advanced entscheiden, was Sie das kostet, und für dieses Rezept gilt:- Lassen Sie Fail on error responses an. Wenn Ihr Endpunkt die Payload ablehnt, soll die Aufgabe das sagen.
- Schalten Sie Continue automation on failure nur an, wenn dieser POST eine Benachrichtigung ist und der Rest des Runs auch ohne ihn lohnend ist. Wenn Sie das tun, füllen Sie auch den Baum Error response (non-2xx) aus, damit eine spätere Aufgabe protokollieren kann, was Ihr Endpunkt tatsächlich gesagt hat.
Aktivieren und die ersten Runs prüfen
Aktivieren Sie die Automatisierung und lassen Sie eine echte Konversation enden. Öffnen Sie dann Runs und finden Sie den Run. Ein abgeschlossener HTTP Request zeigt seine Beschreibung als Titel, mit What will you provide? und What will you get back? darunter, sodass Sie vergleichen können, was gesendet wurde und was Sie konfiguriert haben. Siehe so sieht die Aufgabe in einem Run aus und das Runs-Log. Gleichen Sie die ersten Runs mit den Aufzeichnungen Ihres eigenen Systems ab, bevor Sie sich auf die Automatisierung verlassen. Ein Request, der aus HireData-Sicht erfolgreich war, sagt noch nichts darüber, was Ihr System damit gemacht hat.Brauchen Sie noch Hilfe?
Wenn die Automatisierung gar nicht läuft, liegt das Problem beim Trigger, nicht beim Request. Siehe Warum ist meine Automatisierung nicht gelaufen?. Wenn der Request läuft, aber blockiert zurückkommt, siehe wenn ein Request blockiert zurückkommt. Wenn Sie weiterhin Hilfe brauchen, kontaktieren Sie support@hiredata.com und geben Sie an:- Den Namen der Automatisierung und einen Link zu einem Run
- Die Methode und URL der Aufgabe, mit entferntem Token
- Was Ihr Endpunkt Ihrer Erwartung nach zurückgeben sollte und was er stattdessen zurückgegeben hat