Gestori di stato

I gestori di stato, chiamati semplicemente gestori, vengono utilizzati per controllare la conversazione creando risposte per gli utenti finali e/o eseguendo la transizione della pagina corrente. Per ogni svolta conversazionale, vengono valutati i gestori, che possono influire sulla sessione. I gestori hanno tre tipi generali di dati:

Termine Definizione
Requisiti del gestore Questi sono i requisiti che il gestore deve soddisfare affinché abbia effetto sulla sessione. Un gestore viene definito chiamato quando soddisfa i propri requisiti e influisce in qualche modo sulla sessione.
Fulfillment gestore Se viene chiamato un gestore, viene utilizzato un fulfillment facoltativo per creare risposte per gli utenti finali. Queste risposte vengono definite nei dati degli agenti statici o recuperate dinamicamente dal servizio webhook.
Destinazione della transizione del gestore Se viene chiamato un gestore, viene utilizzata una destinazione facoltativa della transizione per cambiare la pagina corrente. La pagina successiva può essere solo una pagina iniziale del flusso o una pagina all'interno del flusso attualmente attivo.

Esistono due tipi di gestori di stato con requisiti di gestore diversi:

Termine Definizione
Route Le route vengono chiamate quando un input utente finale corrisponde a un intent e/o a una condizione sullo stato della sessione. Una route con un requisito di intent è anche chiamata route intent. Una route con un solo requisito di condizione è anche chiamata route condizionale.
Gestori di eventi I gestori di eventi vengono chiamati quando viene richiamato un evento. Alcuni eventi integrati vengono attivati quando viene ricevuto un input imprevisto dell'utente finale o quando si verifica un errore del webhook. Puoi anche definire eventi personalizzati da richiamare quando si verifica qualcosa al di fuori della conversazione.

L'elaborazione di un gestore di stato prevede tre passaggi:

Termine Definizione
1. Ambito Un gestore deve essere in ambito per avere effetto sulla sessione. L'ambito viene determinato dall'applicazione di un gestore a un flusso, una pagina o un parametro modulo e dall'attivazione o meno del flusso associato, della pagina associata o dell'agente sta attualmente tentando di compilare il parametro modulo associato.
2. Valutazione Ogni gestore nell'ambito viene valutato in base all'ordine. Se i requisiti di un gestore vengono soddisfatti, supera la valutazione.
3. Chiamata Se un gestore rientra nell'ambito e supera la valutazione, viene chiamato. Viene chiamato ogni fulfillment associato e qualsiasi target di transizione associato viene applicato alla sessione.

Ambito

Per poter valutare un gestore, deve essere in ambito. L'ambito Gestore è uno strumento importante e potente che ti aiuta a controllare la conversazione. Controllando l'ambito di un gestore, puoi controllare:

X Elemento
Quando è possibile trovare una corrispondenza per intent
Quando deve essere controllata una condizione
Quando è possibile gestire un determinato evento
Quando si può verificare una transizione di pagina
Quando viene fornita una risposta di fulfillment statica
Quando un fulfillment abilitato per webhook viene chiamato per le risposte dinamiche

L'ambito viene determinato dall'applicazione di un gestore a un flusso, una pagina o un parametro modulo, dall'attivazione o dall'attivazione del flusso associato oppure dall'attivazione o meno dell'agente sta tentando di compilare il parametro modulo associato.

Di seguito sono riportate le regole dettagliate di definizione dell'ambito:

  • Route applicate al flusso attivo:
    • Se la pagina corrente è la pagina iniziale del flusso, rientra nell'ambito.
    • Se la pagina corrente non è la pagina iniziale del flusso, rientrano nell'ambito solo se hanno un requisito di intent.
  • Le route applicate alla pagina corrente rientrano nell'ambito.
  • I gestori di eventi applicati al flusso attivo rientrano nell'ambito.
  • I gestori di eventi applicati alla pagina corrente rientrano nell'ambito.
  • Rientrano nell'ambito i gestori di eventi applicati a un parametro del modulo che l'agente sta attualmente cercando di compilare.

Route

Le route hanno due requisiti e devono essere specificati uno o entrambi. Se vengono forniti entrambi, i requisiti devono essere soddisfatti per poter chiamare la route:

Termine Definizione
Requisito di intent Un intent che deve essere abbinato all'input utente finale per la svolta conversazionale attuale. Quando una route ha un requisito di intent, si chiama route intent.
Requisito della condizione Una condizione che deve essere soddisfatta. Quando una route ha un requisito di condizione, è chiamata route condizione.

Puoi applicare route a flussi (route a livello di flusso) e pagine (route a livello di pagina). Ad esempio, puoi utilizzare le route nelle seguenti situazioni:

X Elemento
Quando l'input utente finale corrisponde a un intent, la corrispondenza dovrebbe attivare una risposta di fulfillment statico.
Quando l'input utente finale corrisponde a un intent, la corrispondenza dovrebbe attivare un fulfillment abilitato per webhook per una risposta dinamica.
Quando l'input utente finale ha fornito il parametro del modulo finale obbligatorio, un controllo delle condizioni attiva una transizione della sessione a un'altra pagina.
Quando l'input utente finale ha fornito uno specifico parametro del modulo, un controllo della condizione attiva una risposta di fulfillment statico.
Un controllo della condizione impostato su true che forza una transizione di pagina.

Propagazione intent

Normalmente, quando una route viene chiamata a causa di un intent corrispondente, l'intent viene consumato. Un intent utilizzato non può essere abbinato di nuovo, a meno che il nuovo input utente finale non attivi una nuova corrispondenza dell'intent. Tuttavia, è possibile propagare una corrispondenza di intent da un flusso a un altro nel seguente scenario:

  • Una route in flow F1 ha intent I1 come requisito e flow F2 come target di transizione.
  • Flow F2 ha un percorso che ha anche intent I1 come requisito.

In questo caso, quando la route in flow F1 viene chiamata, intent I1 viene abbinata due volte per un singolo input utente finale ed vengono chiamate entrambe.

La propagazione degli intent è utile per:

X Elemento
Cambia la pagina corrente in una pagina specifica in un altro flusso (la route del flusso di destinazione della transizione ha una pagina di destinazione specifica per la transizione).
Crea un messaggio di voce per la pagina iniziale di un flusso (la route del flusso di destinazione della transizione ha un fulfillment).

Gruppi di route

Quando crei un agente, potresti scoprire che molte pagine hanno un insieme di route comuni. Per rendere i percorsi riutilizzabili, puoi definire gruppi di percorsi. Puoi creare queste risorse del gruppo riutilizzabili all'interno del flusso o all'interno dell'intero agente.

Ad esempio, potresti voler gestire l'input utente finale come "Voglio aggiungere un condimento alla mia pizza" e "Voglio modificare la dimensione della bevanda". Questi input devono essere gestiti quando è attiva una qualsiasi delle diverse pagine del flusso. Potresti definire due route con intent per gestire questi input per tutte le pagine pertinenti, ma questo richiede molto lavoro duplicato. Puoi invece definire il gruppo di route una sola volta e aggiungere un riferimento al gruppo su tutte le pagine pertinenti.

Gruppi di route a livello di flusso

I gruppi di route a livello di flusso sono risorse di gruppo di route create con un flusso come padre. Sono riutilizzabili all'interno del flusso.

Gruppi di route a livello di agente

I gruppi di route a livello di agente sono risorse di gruppi di route create con un agente come padre. Sono riutilizzabili all'interno dell'intero agente, ma non consentono le route che passano a una pagina non simbolica come destinazione.

Route a livello di flusso

Le route a livello di flusso sono route applicate a un flusso aggiungendole alla pagina iniziale del flusso. Questi tipi di gestori hanno i seguenti casi d'uso:

X Elemento
Gestori con un requisito di intent o condizione nell'ambito della pagina iniziale del flusso.
I gestori con un requisito di intenzione che rientrano nell'ambito di tutte le pagine del flusso.

Per creare route a livello di flusso dalla console:

  1. Apri la pagina iniziale del flusso.
  2. Fai clic sul pulsante Aggiungi nell'intestazione Route.
  3. Si apre il riquadro di modifica del percorso.
  4. Fornisci i campi del percorso.
  5. Fai clic su Salva.

Per riordinare le route a livello di flusso dalla console:

  1. Apri la pagina iniziale del flusso.
  2. Fai clic sull'intestazione Route.
  3. Si apre il riquadro dell'elenco dei percorsi.
  4. Trascina i percorsi nell'ordine desiderato. In alternativa, fai clic sul menu opzione , poi seleziona Sposta in.

Per eliminare le route a livello di flusso dalla console:

  1. Apri la pagina iniziale del flusso.
  2. Fai clic sull'intestazione Route.
  3. Si apre il riquadro dell'elenco dei percorsi.
  4. Fai clic sul menu opzione .
  5. Seleziona Elimina.

Route a livello di pagina

Le route a livello di pagina sono route applicate a una pagina. Questi tipi di gestori hanno i seguenti casi d'uso:

X Elemento
Gestori con un requisito di intent o condizione in ambito quando sono attive pagine specifiche.

Per creare route a livello di pagina dalla console:

  1. Apri la pagina (non la pagina iniziale del flusso).
  2. Fai clic sul pulsante Aggiungi nell'intestazione Route.
  3. Si apre il riquadro di modifica del percorso.
  4. Fornisci i campi del percorso.
  5. Fai clic su Salva.

Per riordinare le route a livello di pagina dalla console:

  1. Apri la pagina (non la pagina iniziale del flusso).
  2. Fai clic sull'intestazione Route.
  3. Si apre il riquadro dell'elenco dei percorsi.
  4. Trascina i percorsi nell'ordine desiderato. In alternativa, fai clic sul menu opzione , poi seleziona Sposta in.

Per eliminare le route a livello di pagina dalla console:

  1. Apri la pagina (non la pagina iniziale del flusso).
  2. Fai clic sull'intestazione Route.
  3. Si apre il riquadro dell'elenco dei percorsi.
  4. Fai clic sul menu opzione .
  5. Seleziona Elimina.

Gestori di eventi

I gestori di eventi hanno un requisito per poter essere chiamati:

Termine Definizione
Requisito dell'evento Un evento che deve essere richiamato. Gli eventi sono identificati dal relativo nome. Alcuni eventi integrati vengono richiamati quando viene ricevuto un input imprevisto dell'utente finale o quando si verifica un errore del webhook. Puoi anche definire eventi personalizzati da richiamare quando accade qualcosa al di fuori della conversazione.

Puoi applicare gestori di eventi a flussi (gestori di eventi a livello di flusso), pagine (gestori di eventi a livello di pagina) e parametri (gestori di eventi a livello di parametro). Ad esempio, puoi utilizzare i gestori di eventi nelle seguenti situazioni:

X Elemento
Quando l'input utente finale non corrisponde ad alcun intent, un gestore di eventi no-match fornisce una risposta specifica di fulfillment statico.
Un timer scade nel sistema e vuoi fornire informazioni di promemoria all'utente finale con una specifica risposta di fulfillment statico.

Gestori di eventi a livello di flusso

I gestori di eventi a livello di flusso sono gestori di eventi che vengono applicati a un flusso. Questi tipi di gestori hanno i seguenti casi d'uso:

X Elemento
Gestori con un requisito di evento nell'ambito della pagina iniziale del flusso.
I gestori con un requisito di evento nell'ambito di tutte le pagine del flusso.
Gestione degli input imprevisti dell'utente finale, condivisi da tutte le pagine in un flusso.
Gestione degli errori del webhook, condivisi da tutte le pagine di un flusso.
Gestione degli eventi personalizzati richiamati dal sistema e condivisi da tutte le pagine di un flusso.

Ogni flusso ha gestori di eventi per gli eventi integrati no-match e no-input. Questi gestori di eventi vengono creati automaticamente quando crei un flusso e non possono essere eliminati.

Per creare gestori di eventi a livello di flusso dalla console:

  1. Apri la pagina iniziale del flusso.
  2. Fai clic sul pulsante Aggiungi nell'intestazione Gestori di eventi.
  3. Si apre il riquadro del gestore di eventi.
  4. Fornisci i campi del gestore di eventi.
  5. Fai clic su Salva.

Per eliminare i gestori di eventi a livello di flusso dalla console:

  1. Apri la pagina iniziale del flusso.
  2. Fai clic sull'intestazione Gestori di eventi.
  3. Si apre il riquadro dell'elenco dei gestori di eventi.
  4. Passa il mouse sopra un gestore di eventi, quindi fai clic sul pulsante Elimina .

Gestori di eventi a livello di pagina

I gestori di eventi a livello di pagina sono gestori di eventi applicati a una pagina. Questi tipi di gestori hanno i seguenti casi d'uso:

X Elemento
Gestori con un requisito di evento nell'ambito di applicazione quando sono attive pagine specifiche.
Gestione degli input imprevisti dell'utente finale, specifici di una pagina.
Gestione degli errori del webhook, specifici di una pagina.
Gestione di eventi personalizzati richiamati dal sistema specifici di una pagina.

Per creare gestori di eventi a livello di pagina dalla console:

  1. Apri una pagina (non la pagina iniziale del flusso).
  2. Se non è presente un'intestazione Gestori di eventi, fai clic su Aggiungi gestore di stato, seleziona Gestori di eventi e fai clic su Applica.
  3. Fai clic sul pulsante Aggiungi nell'intestazione Gestori di eventi.
  4. Si apre il riquadro del gestore di eventi.
  5. Fornisci i campi del gestore di eventi.
  6. Fai clic su Salva.

Per eliminare i gestori di eventi a livello di pagina dalla console:

  1. Apri una pagina (non la pagina iniziale del flusso).
  2. Fai clic sull'intestazione Gestori di eventi.
  3. Si apre il riquadro dell'elenco dei gestori di eventi.
  4. Passa il mouse sopra un gestore di eventi, quindi fai clic sul pulsante Elimina .

Gestori di eventi a livello di parametro

I gestori di eventi a livello di parametro sono gestori di eventi applicati a un parametro del modulo. Sono anche noti come gestori di ripetizione. Questi gestori di eventi non consentono gli eventi personalizzati, in quanto sono pensati specificatamente per gestire l'input utente finale non valido durante la compilazione del modulo.

Questi tipi di gestori hanno i seguenti casi d'uso:

X Elemento
L'utente finale non ha fornito un input valido quando gli è stato chiesto di compilare un parametro del modulo.

Per creare gestori di eventi a livello di parametro dalla console:

  1. Apri una pagina contenente parametri del modulo.
  2. Fai clic su un parametro.
  3. Si apre il riquadro dei parametri.
  4. Scorri verso il basso fino alla sezione Gestori di eventi Reprompt, quindi fai clic su Aggiungi gestore di eventi.
  5. Si apre il riquadro del gestore di eventi.
  6. Fornisci i campi del gestore di eventi.
  7. Fai clic su Salva.

Per eliminare i gestori di eventi a livello di parametro dalla console:

  1. Apri una pagina contenente parametri del modulo.
  2. Fai clic su un parametro.
  3. Si apre il riquadro dei parametri.
  4. Scorri verso il basso fino alla sezione Gestori di eventi Reprompt.
  5. Passa il mouse sopra un gestore di eventi, quindi fai clic sul pulsante Elimina .

Eventi integrati

I seguenti eventi sono integrati e richiamati da Dialogflow. Alcuni eventi sono limitati a determinati livelli.

Nome evento
 A livello di flusso A livello di pagina A livello di parametro Richiamato quando
sys.no-match-default ✔ ✔ ✔
  • A livello di flusso o pagina: l'input utente finale non corrisponde ad alcun intent per i gestori che rientrano nell'ambito.
  • A livello di parametro: l'input utente finale non soddisfa il parametro del modulo.
sys.no-match-[1-6] ✔ ✔ ✔ Se fornisci gestori per uno qualsiasi di questi eventi in ordine numerico, vengono richiamati al posto di sys.no-match-default e nell'ordine: sys.no-match-1, sys.no-match-2, ...
sys.no-input-default ✔ ✔ ✔ L'input utente finale non è stato ricevuto. È possibile attivare questa funzionalità quando:
  • Dialogflow riceve un input di testo vuoto per l'utente finale.
  • Dialogflow riceve un input audio vuoto dell'utente finale oppure l'input non contiene comandi vocali riconosciuti.
  • Si verifica nessun timeout della voce prima che l'input audio dell'utente finale contenga testo riconosciuto.
sys.no-input-[1-6] ✔ ✔ ✔ Se fornisci gestori per uno qualsiasi di questi eventi in ordine numerico, vengono richiamati al posto di sys.no-input-default e nell'ordine: sys.no-input-1, sys.no-input-2, ...
sys.invalid-parameter ✔ Richiamato quando una risposta webhook rende il parametro non valido impostando WebhookResponse.pageInfo.formInfo.parameterInfo.state su INVALID.
sys.long-utterance ✔ ✔ ✔ L'input utente finale supera la lunghezza massima consentita (256 caratteri) corrispondente a intent non generativi o parametri. Se non specificato, Dialogflow considera le frasi lunghe dell'utente come no-match. Per gli input audio in streaming, questo evento viene attivato solo dopo che il client chiude lo stream audio.
webhook.error ✔ ✔ La chiamata webhook ha restituito un errore. Questo evento viene richiamato solo: 1) se non esiste un gestore di eventi webhook granulare (ad es. webhook.error.timeout) che corrisponde al codice di errore del webhook, 2) se nella route originale non è stata impostata una destinazione della transizione che ha chiamato il fulfillment con il webhook in errore. Per informazioni dettagliate, consulta la sezione relativa all'ordine di valutazione.
webhook.error.timeout ✔ ✔ La chiamata webhook è scaduta. Un evento webhook viene richiamato solo se non è stata impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook con errori. Per informazioni dettagliate, consulta la sezione relativa all'ordine di valutazione.
webhook.error.bad-request ✔ ✔ Il webhook ha restituito 400 richieste non valide. Un evento webhook viene richiamato solo se non è stata impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook con errori. Per informazioni dettagliate, consulta la sezione relativa all'ordine di valutazione.
webhook.error.rejected ✔ ✔ Il webhook ha restituito lo stato 401 Autorizzazione non autorizzata o 403 Accesso negato. Un evento webhook viene richiamato solo se non è stata impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook con errori. Per informazioni dettagliate, consulta la sezione relativa all'ordine di valutazione.
webhook.error.unavailable ✔ ✔ Il webhook ha restituito 503 Service Non disponibile. Un evento webhook viene richiamato solo se non è stata impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook con errori. Per informazioni dettagliate, consulta la sezione relativa all'ordine di valutazione.
webhook.error.not-found ✔ ✔ La chiamata webhook non è riuscita perché l'URL webhook non era raggiungibile. Un evento webhook viene richiamato solo se non è stata impostata una destinazione di transizione nella route originale che ha chiamato il fulfillment con il webhook con errori. Per informazioni dettagliate, consulta la sezione relativa all'ordine di valutazione.
flow-cancelled ✔ ✔ L'utente finale ha richiesto l'annullamento del flusso. Questo evento viene attivato dalla pagina Termina flusso con cancellazione, vedi la destinazione della transizione simbolica a END_FLOW_WITH_CANCELLATION.
flow-failed ✔ ✔ Questo flusso non è stato in grado di completare l'attività specificata. Questo evento viene attivato dalla pagina Flusso finale con errore; vedi la destinazione della transizione simbolica a END_FLOW_WITH_FAILURE.
flow-failed-human-escalation ✔ ✔ L'utente finale ha chiesto di parlare con gli agenti umani. Questo evento viene attivato dalla pagina Termina flusso con riassegnazione umana; vedi la target per la transizione simbolica di END_FLOW_WITH_HUMAN_ESCALATION.

Eventi personalizzati

Puoi creare eventi e gestori di eventi personalizzati. Gli eventi personalizzati vengono utilizzati per gestire gli eventi al di fuori della conversazione con l'utente finale. Ad esempio, l'utente finale ha fatto clic su un pulsante, è trascorso un determinato periodo di tempo, l'inventario disponibile è cambiato durante la conversazione e così via.

Gli eventi sono semplicemente identificati per nome. Evita di utilizzare nomi di eventi che iniziano con sys. o webhook. per evitare conflitti con gli eventi integrati.

Per richiamare un evento con l'API, consulta il campo queryInput.event del metodo detectIntent per il tipo Session.

Seleziona un protocollo e una versione per il riferimento sessione:

Protocollo V3 V3beta1
REST Risorsa sessione Risorsa sessione
RPC Interfaccia sessione Interfaccia sessione
C++ SessionsClient Non disponibile
C# SessionsClient Non disponibile
Go SessionsClient Non disponibile
Java SessionsClient SessionsClient
Node.js SessionsClient SessionsClient
PHP Non disponibile Non disponibile
Python SessionsClient SessionsClient
Ruby Non disponibile Non disponibile

Ordine di valutazione

I gestori vengono valutati in un ordine specifico. Si applicano le seguenti regole generali:

  1. Vengono valutati solo i gestori nell'ambito.
  2. Possono essere chiamati solo i gestori i cui requisiti sono soddisfatti.
  3. Se viene chiamato un gestore senza una destinazione di transizione, la valutazione dell'elenco di gestori continua. A causa di questa regola, più fulfillment possono aggiungere più messaggi alla coda di risposta.
  4. Se viene chiamato un gestore con una destinazione di transizione, la valutazione dell'elenco di gestori termina.
  5. Se viene chiamato un gestore con fulfillment e il fulfillment genera un errore webhook:
    • Se per il gestore è stata definita una destinazione, il webhook non funziona correttamente.
    • Se un gestore di eventi rientra nell'ambito dell'evento, gestisce l'evento e la valutazione della fine dell'elenco di gestori.
    • Se nessun gestore di eventi rientra nell'ambito dell'evento, il webhook non funziona automaticamente.
  6. Quando un requisito di intent è soddisfatto, l'intent viene utilizzato, quindi è possibile chiamare solo il primo gestore di route trovato per l'intent (per le eccezioni, consulta la propagazione dell'intent).
  7. Quando un requisito della condizione è soddisfatto, la condizione non viene consumata, quindi è possibile chiamare più route con la condizione.
  8. Quando il requisito di un evento è soddisfatto, l'evento viene consumato, quindi è possibile chiamare solo il primo gestore di eventi trovato per l'evento.
  9. Lo stack di chiamate del gestore può influire sull'ordine di valutazione.

La valutazione si articola in tre fasi:

  1. Le route che hanno un requisito di intent vengono valutate in questo ordine:
    1. A livello di pagina: singole route applicate alla pagina corrente, nell'ordine indicato.
    2. Gruppi a livello di pagina: gruppi di route applicati alla pagina corrente, nell'ordine indicato.
    3. A livello di flusso: route applicate al flusso attivo, nell'ordine indicato.
    4. Gruppi a livello di flusso: gruppi di route applicati al flusso attivo, nell'ordine specificato.
  2. Le route che presentano un solo requisito di condizione vengono valutate in questo ordine:
    1. A livello di pagina: singole route applicate alla pagina corrente, nell'ordine indicato.
    2. Gruppi a livello di pagina: gruppi di route applicati alla pagina corrente, nell'ordine specificato.
    3. A livello di flusso (solo se la pagina corrente è la pagina iniziale del flusso): route applicate al flusso attivo, nell'ordine specificato.
    4. Gruppi a livello di flusso (solo se la pagina corrente è la pagina iniziale del flusso): gruppi di route applicati al flusso attivo, nell'ordine specificato.
  3. I gestori di eventi vengono valutati in questo ordine:
    1. A livello di parametro: gestori di eventi applicati al parametro di modulo della pagina corrente che l'agente sta attualmente cercando di compilare (gestori di ripetizione), nell'ordine indicato.
    2. A livello di pagina: gestori di eventi applicati alla pagina corrente, nell'ordine indicato.
    3. A livello di flusso: gestori di eventi applicati al flusso attivo nell'ordine indicato.

Target di transizione simbolici

Quando inserisci una destinazione di transizione per un gestore, puoi inserire flussi o pagine specifici, ma anche obiettivi di transizione simbolici:

Destinazione della transizione simbolica
 Descrizione
START_PAGE Passa alla pagina iniziale del flusso attivo con lo stesso nome.
END_FLOW Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione a quello attuale. Vedi anche Stack di chiamate gestore e limite di stack di flussi.
END_FLOW_WITH_CANCELLATION Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione a quello attuale. La pagina Chiamate può gestire questa transizione con l'evento integrato flow-cancelled. Vedi anche Stack di chiamate gestore e limite di stack di flussi.
END_FLOW_WITH_FAILURE Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione a quello attuale. La pagina Chiamate può gestire questa transizione con l'evento integrato flow-failed. Vedi anche Stack di chiamate gestore e limite di stack di flussi.
END_FLOW_WITH_HUMAN_ESCALATION Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione a quello attuale. La pagina Chiamate può gestire questa transizione con l'evento integrato flow-failed-human-escalation. Vedi anche Stack di chiamate gestore e limite di stack di flussi.
END_SESSION Cancella la sessione corrente e la transizione alla pagina speciale denominata END_SESSION. L'input utente successivo riavvia la sessione dalla pagina iniziale del flusso di avvio predefinito.
PREVIOUS_PAGE Transizione alla pagina precedente che ha causato una transizione alla pagina corrente. Lo stato della pagina precedente verrà ripristinato dopo la transizione.
CURRENT_PAGE Ritransizione alla pagina corrente. Questo può essere utile se vuoi che l'agente ripeta qualcosa.

Limite dello stack di chiamate del gestore e dello stack di flussi

Quando una sessione passa dal flusso al flusso con target di transizione specifici, ogni flusso viene inviato allo stack di flusso.

Stack di chiamate gestore

Quando una sessione passa a END_FLOW, torna alla pagina di chiamata che ha causato una transizione al flusso completato. In questo caso, lo stack di chiamate del gestore viene conservato. Tutti i gestori valutati in precedenza dalla pagina delle chiamate verranno ignorati e i restanti gestori verranno valutati in ordine.

Ad esempio:

  1. La pagina P ha tre gestori in questo ordine: H1, H2 e H3.
  2. H1 viene valutato, ma non determina una transizione.
  3. H2 viene valutato e determina una transizione al flusso F.
  4. Una pagina nel flusso F passa a END_FLOW.
  5. La sessione torna alla Pagina P, che diventa di nuovo attiva mantenendo lo stato.
  6. La valutazione del gestore nella pagina P continua dallo stato conservato, quindi viene valutata H3.

Limite stack di flusso

Il limite massimo dello stack di flussi è 25. Il superamento del limite massimo dello stack potrebbe causare l'uscita dei flussi dallo stack, causando comportamenti imprevisti durante l'utilizzo della transizione END_FLOW. Per evitare questi potenziali problemi, riduci al minimo il numero di transizioni da flusso a flusso che precedono la transizione END_FLOW.

Se lo stack di flussi è vuoto, la transizione di END_FLOW termina la sessione.

Imposta le condizioni

Per impostare le conditions con la console, puoi fornire le regole di condizione con una delle tre opzioni logiche:

  • Deve corrispondere almeno a una regola (OR)
  • Soddisfa OGNI regola (AND)
  • Personalizza espressione

Per comodità, puoi utilizzare le opzioni AND/OR per creare condizioni semplici o composte per i valori dei parametri.

Puoi utilizzare l'opzione Personalizza espressione in formato libero per tutti i tipi di condizioni, incluse le funzioni di sistema e le boolean constants.

Ad esempio, per impostare una condizione che ha una probabilità del 10% di superare la valutazione, seleziona l'opzione Personalizza espressione e inserisci $sys.func.rand() < 0.1 nel campo Condizione:

Screenshot dell'impostazione di una condizione personalizzata

Indietro
Pagine
Avanti
Intent