Alcuni prodotti e funzionalità sono in fase di ridenominazione. È in corso la migrazione anche delle funzionalità di flusso e playbook generativi in un'unica console consolidata. Consulta i dettagli.

Questa pagina è stata tradotta dall'API Cloud Translation.

Gestori di stato

Gestori di stato, chiamati anche semplicemente gestori, vengono utilizzati per controllare la conversazione creando risposte per gli utenti finali e/o eseguendo la transizione della pagina corrente. Per ogni turno di conversazione, gli handler vengono valutati e possono influire sulla sessione. Gli handler hanno tre tipi generali di dati:

Termine	Definizione
Requisiti per i gestori	Questi sono i requisiti che devono essere soddisfatti affinché il gestore abbia alcun effetto sulla sessione. Si dice che un gestore viene chiamato quando soddisfa i suoi requisiti e influisce in qualche modo sulla sessione.
Fulfillment dell'handler	Se viene chiamato un gestore, viene utilizzato un fulfillment facoltativo per creare risposte per gli utenti finali. Queste risposte sono definiti nei dati statici dell'agente o recuperato dinamicamente dal tuo servizio webhook.
Destinazione della transizione dell'handler	Se viene chiamato un gestore, viene utilizzato un target di transizione facoltativo per modificare la pagina corrente. La pagina successiva può contenere solo pagina iniziale di Flow o una pagina nel flusso attualmente attivo.

Esistono due tipi di gestori di stato con requisiti diversi:

Termine	Definizione
Route	Percorsi vengono richiamati quando l'input di un utente finale corrisponde a intent e/o alcune condizione sullo stato della sessione. Un percorso con un requisito di intent è chiamato anche percorso di intent. Un percorso con solo un requisito di condizione è chiamato anche percorso con condizione.
Gestori di eventi	I gestori di eventi vengono chiamati quando viene invocato un evento. Alcuni eventi integrati vengono attivati quando viene ricevuto un input utente finale imprevisto o quando si verifica un errore del webhook. Puoi anche definire eventi personalizzati che vengono richiamati quando accade qualcosa al di fuori della conversazione.

Esistono tre passaggi per l'elaborazione di un gestore dello stato:

Termine	Definizione
1. Ambito	Un gestore deve essere in ambito per avere effetto sulla sessione. L'ambito è determinato dal fatto che un gestore sia applicato a un flusso, a una pagina o a un parametro di modulo e dal fatto che il flusso associato sia attivo, la pagina associata sia attiva o l'agente stia attualmente tentando di compilare il parametro di modulo associato.
2. Valutazione	Ogni gestore nell'ambito viene valutato in ordine. Se i requisiti di un gestore vengono soddisfatti, il gestore supera la valutazione.
3. Chiamata	Se un gestore è nell'ambito e supera la valutazione, viene chiamato. Viene chiamato qualsiasi adempimento associato e qualsiasi target di transizione associato viene applicato alla sessione.

Ambito

Affinché un gestore venga valutato, deve rientrare nell'ambito. L'ambito del 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 un'intenzione
	Quando è necessario controllare una condizione
	Quando è possibile gestire un determinato evento
	Quando può verificarsi una transizione di pagina
	Quando viene fornita una risposta di completamento statica
	Quando un fulfillment abilitato per webhook viene chiamato per le risposte dinamiche

L'ambito è determinato dal fatto che un gestore sia applicato a un flusso, a una pagina o a un parametro di un modulo e dal fatto che il flusso associato sia attivo, la pagina associata sia attiva o l'agente stia tentando di compilare il parametro del modulo associato.

Le regole di ambito dettagliate sono le seguenti:

Route applicate al flusso attivo:
- Se la pagina corrente è pagina iniziale di Flow, rientrano nel loro ambito.
- Se la pagina corrente non è la pagina iniziale del flusso, rientrano nell'ambito solo se prevedono 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.
I gestori eventi applicati a un parametro del modulo che l'agente sta tentando di compilare rientrano nell'ambito.

Route

I percorsi hanno due requisiti e devi fornire uno o entrambi. Se vengono forniti entrambi i requisiti, devono essere entrambi soddisfatti per chiamare la route:

Termine	Definizione
Requisito per l'intent	Un intento che deve essere associato all'input dell'utente finale per il turno di conversazione corrente. Quando un percorso ha un requisito di intent, viene chiamato percorso con intent.
Requisito della condizione	Una condizione che deve essere soddisfatta. Quando un percorso ha un requisito di condizione, viene chiamato percorso con condizione.

Puoi applicare route ai flussi (route a livello di flusso) e pagine (percorsi a livello di pagina). Ad esempio, potresti utilizzare i percorsi nelle seguenti situazioni:

X	Elemento
	Quando l'input dell'utente finale corrisponde a un'intenzione, la corrispondenza deve attivare una risposta di adempimento statico.
	Quando input utente finale corrisponde a un intent, la corrispondenza deve attivare fulfillment abilitato per webhook per una risposta dinamica.
	Quando l'input dell'utente finale ha fornito il parametro del modulo richiesto finale, un controllo delle condizioni attiva una transizione di sessione a un'altra pagina.
	Quando l'input utente finale ha fornito una specifica parametro modulo un controllo delle condizioni attiva fulfillment statica la risposta corretta.
	Un controllo della condizione impostato su `true` che forza la transizione di una pagina.

Propagazione di intent

Di solito, quando una route viene chiamata per un intent corrispondente, l'intent è consumato. Un'intenzione consumata non può essere associata di nuovo, a meno che un nuovo input dell'utente finale non attivi una nuova corrispondenza dell'intenzione. Tuttavia, è possibile propagare una corrispondenza di intent da un flusso all'altro nel seguente scenario:

Un percorso in flow F1 ha intent I1 come requisito e flow F2 come target di transizione.
Flow F2 ha una route che ha anche intent I1 come requisito.

In questo caso, quando viene chiamato il percorso in flow F1,intent I1 viene associato due volte per un singolo input dell'utente finale e vengono chiamati entrambi i percorsi.

La propagazione degli intent è utile per:

X	Elemento
	Cambia la pagina corrente in una pagina specifica in un altro flusso (il percorso del flusso di destinazione della transizione ha una pagina di destinazione della transizione specifica).
	Crea un messaggio di entrata per la pagina di inizio di un flusso (il percorso del flusso di destinazione della transizione ha un completamento).

Gruppi di route

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

Ad esempio, potresti volere che il flusso gestisca l'input dell'utente finale, come "Voglio aggiungere un condimento alla mia pizza" e "Voglio cambiare la dimensione della mia bevanda". Questi input devono essere gestiti quando una delle più pagine del flusso è attiva. Puoi definire due route con intent per gestire questi input per tutte le pagine pertinenti, ma si tratta di un lavoro duplicato. Puoi invece definire il gruppo di route una volta e aggiungi 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 gruppi di route create con un protocollo come genitore. 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 una come agente principale. Sono riutilizzabili nell'intero agente, ma non consentono percorsi che passano a una pagina non simbolica come target.

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 in ambito per la pagina di inizio del flusso.
	Gestori con un requisito di intent nell'ambito per tutte le pagine all'interno del flusso.

Per creare route a livello di flusso dalla console:

Apri la pagina iniziale del flusso.
Fai clic sul pulsante Aggiungi nell'intestazione Route.
Viene visualizzato il riquadro di modifica del percorso.
Fornisci i campi del percorso.
Fai clic su Salva.

Per riordinare le route a livello di flusso dalla console:

Apri la pagina iniziale del flusso.
Fai clic sull'intestazione Percorsi.
Si apre il riquadro dell'elenco dei percorsi.
Trascina i percorsi nell'ordine che preferisci. In alternativa, fai clic sull'opzione Menu , quindi seleziona Sposta in.

Per eliminare le route a livello di flusso dalla console:

Apri la pagina di inizio del flusso.
Fai clic sull'intestazione Percorsi.
Si apre il riquadro dell'elenco dei percorsi.
Fai clic sul menu dell'opzione .
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 percorsi a livello di pagina dalla console:

Apri la pagina (non la pagina iniziale del flusso).
Fai clic sul pulsante Aggiungi nell'intestazione Route.
Viene visualizzato il riquadro di modifica del percorso.
Fornisci i campi del percorso.
Fai clic su Salva.

Per riordinare i percorsi a livello di pagina dalla console:

Apri la pagina (non la pagina iniziale del flusso).
Fai clic sull'intestazione Route.
Si apre il riquadro dell'elenco dei percorsi.
Trascina i percorsi nell'ordine che preferisci. In alternativa, fai clic sul menu opzioni e seleziona Sposta in.

Per eliminare le route a livello di pagina dalla console:

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

Gestori di eventi

I gestori di eventi hanno un requisito per essere chiamati:

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

Puoi applicare gestori di eventi ai 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, potresti utilizzare i gestori di eventi nelle seguenti situazioni:

X	Elemento
	Quando l'input dell'utente finale non corrisponde a nessun'intenzione, un gestore eventi senza corrispondenza fornisce una risposta specifica di soddisfazione statica.
	Un timer scade nel sistema, e vuoi fornire informazioni di promemoria per l'utente finale con fulfillment statica la risposta corretta.

Gestori di eventi a livello di flusso

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

X	Elemento
	Gestori con un requisito di evento nell'ambito del pagina iniziale di Flow.
	Gestori con un requisito relativo agli eventi che rientra nell'ambito di tutte le pagine del flusso.
	Gestione di input imprevisti da parte dell'utente finale, condivisi da tutte le pagine di un flusso.
	Gestione degli errori dei webhook, condivisi da tutte le pagine di un flusso.
	Per gestire gli eventi personalizzati richiamati dal tuo sistema, condivise da tutte le pagine di un flusso.

Ogni flusso ha gestori di eventi per no-match e no-input eventi integrati. 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:

Apri la pagina iniziale del flusso.
Fai clic sul pulsante Aggiungi nell'intestazione Gestione eventi.
Si apre il riquadro del gestore di eventi.
Fornisci i campi del gestore di eventi.
Fai clic su Salva.

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

Apri la pagina di inizio del flusso.
Fai clic sull'intestazione Gestori di eventi.
Viene visualizzato il riquadro dell'elenco dei gestori degli eventi.
Passa il mouse sopra un gestore 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 quando sono attive pagine specifiche.
	Gestione di input imprevisti da parte dell'utente finale, specifici per una pagina.
	Gestione degli errori relativi ai webhook, specifici di una pagina.
	Gestire gli eventi personalizzati invocati dal sistema, specifici per una pagina.

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

Apri una pagina (non la pagina iniziale del flusso).
Se non è presente l'intestazione Gestione eventi, fai clic su Aggiungi gestore stato, seleziona Gestione eventi, poi fai clic su Applica.
Fai clic sul pulsante Aggiungi nella sezione Gestione eventi.
Si apre il riquadro del gestore di eventi.
Fornisci i campi del gestore di eventi.
Fai clic su Salva.

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

Apri una pagina (non la pagina iniziale del flusso).
Fai clic sull'intestazione Gestione eventi.
Viene visualizzato il riquadro dell'elenco dei gestori degli eventi.
Passa il mouse sopra un gestore 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. applicate a un parametro del modulo. Sono noti anche come gestori di richieste di conferma. Questi gestori di eventi non consentono eventi personalizzati, poiché sono progettati specificamente per gestire input non validi da parte dell'utente finale 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:

Apri una pagina contenente i parametri del modulo.
Fai clic su un parametro.
Si apre il riquadro dei parametri.
Scorri verso il basso fino alla sezione Gestione eventi di richiesta di conferma, poi fai clic su Aggiungi gestore eventi.
Si apre il riquadro del gestore di eventi.
Fornisci i campi del gestore di eventi.
Fai clic su Salva.

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

Apri una pagina contenente i parametri del modulo.
Fai clic su un parametro.
Si apre il riquadro dei parametri.
Scorri verso il basso fino alla sezione Gestori di eventi di richiesta di conferma.
Passa il mouse sopra un gestore di eventi, quindi fai clic su Elimina Pulsante .

Eventi integrati

I seguenti eventi sono integrati e vengono richiamati dagli agenti conversazionali (Dialogflow CX). Alcuni eventi sono limitati a determinati livelli.

Nome evento	A livello di flusso	A livello di pagina	A livello di parametro	Richiamata quando
`sys.no-match-default`	✔	✔	✔	A livello di flusso o pagina: input utente finale non corrisponde ad alcun intent per i gestori che rientrano nell'ambito. Per il livello parameter: l'input dell'utente finale non soddisfa il parametro del modulo.
`sys.no-match-[1-6]`	✔	✔	✔	Se fornisci gestori per uno di questi eventi ordinati numericamente, vengono richiamati anziché `sys.no-match-default` e in ordine: `sys.no-match-1`, `sys.no-match-2` e così via.
`sys.no-input-default`	✔	✔	✔	Input utente finale non ricevuto. Questa opzione può essere richiamata quando: Gli agenti conversazionali (Dialogflow CX) ricevono un input di testo vuoto dell'utente finale. Gli agenti conversazionali (Dialogflow CX) ricevono un input audio dell'utente finale vuoto o l'input non contiene alcun parlato riconosciuto. Un timeout per assenza di parlato si verifica prima che l'input audio dell'utente finale contenga parlato riconosciuto.
`sys.no-input-[1-6]`	✔	✔	✔	Se fornisci gestori per uno qualsiasi di questi eventi ordinati numericamente, vengono richiamati anziché `sys.no-input-default` e in ordine: `sys.no-input-1`, `sys.no-input-2`, ...
`sys.invalid-parameter`			✔	Viene invocato quando una risposta webhook invalida il parametro impostando `WebhookResponse.pageInfo.formInfo.parameterInfo.state` su `INVALID`.
`sys.long-utterance`	✔	✔	✔	L'input dell'utente finale supera la lunghezza massima consentita (256 caratteri) abbinata a intent non generativi o parametri. Se non viene specificato, gli agenti conversazionali (Dialogflow CX) considerano le espressioni 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 invocato solo: 1) se non esiste un gestore di eventi webhook granulare (ad es. webhook.error.timeout) che corrisponda al codice di errore webhook, 2) se non è impostato un target di transizione nel percorso originale che ha chiamato l'elaborazione con il webhook con errore. Per maggiori dettagli, consulta la sezione Ordine di valutazione.
`webhook.error.timeout`	✔	✔		La chiamata webhook è scaduta. Un evento webhook verrà richiamato solo se nella route originale non è impostata una destinazione di transizione che chiamava il fulfillment con il webhook con errore. Per informazioni dettagliate, consulta la sezione Ordine di valutazione.
`webhook.error.bad-request`	✔	✔		Il webhook ha restituito 400 Bad Request. Un evento webhook verrà richiamato solo se nella route originale non è impostata una destinazione di transizione che chiamava il fulfillment con il webhook con errore. Per maggiori dettagli, consulta la sezione Ordine di valutazione.
`webhook.error.rejected`	✔	✔		Il webhook ha restituito 401 Autorizzazione non autorizzata o 403 Accesso negato. Un evento webhook viene invocato solo se non è impostato un target di transizione nel percorso originale che ha chiamato l'elaborazione con il webhook non riuscito. Per informazioni dettagliate, consulta la sezione Ordine di valutazione.
`webhook.error.unavailable`	✔	✔		Il webhook ha restituito 503 Service Unavailable. Un evento webhook viene invocato solo se non è impostato un target di transizione nel percorso originale che ha chiamato l'elaborazione con il webhook non riuscito. Per maggiori dettagli, consulta la sezione Ordine di valutazione.
`webhook.error.not-found`	✔	✔		Chiamata webhook non riuscita perché l'URL webhook non è raggiungibile. Un evento webhook viene invocato solo se non è impostato un target di transizione nel percorso originale che ha chiamato l'elaborazione con il webhook non riuscito. Per maggiori dettagli, consulta la sezione Ordine di valutazione.
`flow-cancelled`	✔	✔		L'utente finale ha richiesto l'annullamento del flusso. Questo evento viene attivato dalla pagina Termina flusso con annullamento. Vedi il target simbolico della transizione `END_FLOW_WITH_CANCELLATION`.
`flow-failed`	✔	✔		Questo flusso non è stato in grado di completare l'attività specificata. Questo evento viene attivato dalla pagina Termina flusso con errore. Consulta `END_FLOW_WITH_FAILURE` Destinazione transizione simbolica.
`flow-failed-human-escalation`	✔	✔		L'utente finale ha chiesto di parlare con agenti umani. Questo evento viene attivato dalla pagina Termina flusso con riassegnazione a un addetto, consulta il `END_FLOW_WITH_HUMAN_ESCALATION` target di transizione simbolica.

Eventi personalizzati

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

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

Per richiamare un evento con l'API, vedi 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 di sessione	Risorsa sessione
RPC	Interfaccia di sessione	Interfaccia della sessione
C++	SessionsClient	Non disponibile
C#	SessionsClient	Non disponibile
Vai	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:

Vengono valutati solo i gestori in scope.
Possono essere chiamati solo i gestori i cui requisiti sono soddisfatti.
Se viene chiamato un gestore senza una destinazione di transizione, dell'elenco dei gestori continua. A causa di questa regola, più completamenti possono aggiungere più messaggi alle coda di risposte.
Se viene chiamato un gestore con un target di transizione, la valutazione dell'elenco di gestori termina.
Se viene chiamato un gestore con fulfillment, e il fulfillment genera un errore relativo al webhook:
- Se per il gestore è stata definita una destinazione della transizione, il webhook non riesce automaticamente.
- Se un gestore eventi è nell'ambito dell'evento, lo gestisce e la valutazione dell'elenco dei gestori termina.
- Se non è presente alcun gestore eventi per l'evento, il webhook non genera errori.
Quando viene soddisfatto un requisito di intent, l'intento viene consumato, quindi solo il primo gestore di route trovato per l'intent (vedi propagazione dell'intent per le eccezioni).
Quando un requisito di condizione è soddisfatto, poiché la condizione non viene consumata, quindi con la condizione.
Quando un requisito di evento è soddisfatto, l'evento viene utilizzato, quindi può essere chiamato solo il primo gestore di eventi trovato per l'evento.
Lo stack di chiamate del gestore possono influenzare l'ordine di valutazione.

La valutazione si suddivide in tre fasi:

I percorsi con un requisito di intent vengono valutati in questo ordine:
1. A livello di pagina: Singole route applicate alla pagina corrente nell'ordine fornito.
2. Gruppi a livello di pagina: Gruppi di route applicati alla pagina corrente, nell'ordine fornito.
3. A livello di flusso: Route applicate al flusso attivo, nell'ordine fornito.
4. Gruppi a livello di flusso: Gruppi di route applicati al flusso attivo, nell'ordine specificato.
Le route con un solo requisito di condizione vengono valutate in questo ordine:
1. A livello di pagina: i singoli percorsi applicati alla pagina corrente, nell'ordine specificato.
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 di inizio del flusso): Percorsi applicati al flusso attivo, nell'ordine specificato.
4. Gruppi a livello di flusso (solo se la pagina corrente è la pagina di inizio del flusso): Gruppi di route applicati al flusso attivo, nell'ordine specificato.
I gestori di eventi vengono valutati in questo ordine:
1. A livello di parametro: i gestori eventi applicati al parametro del modulo della pagina corrente che l'agente sta tentando di compilare (gestori di richiesta di ripetizione), nell'ordine specificato.
2. A livello di pagina: i gestori di eventi applicati alla pagina corrente nell'ordine fornito.
3. A livello di flusso: gestori di eventi applicati al flusso attivo, nell'ordine fornito.

Target di transizione simbolici

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

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 al flusso attuale. Vedi anche Stack delle chiamate del gestore e limite dello stack di flusso.
`END_FLOW_WITH_CANCELLATION`	Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione al flusso attuale. La pagina di chiamata può gestire questa transizione con l'evento integrato `flow-cancelled`. Consulta anche Limite dello stack di chiamate e dello stack del flusso dell'handler.
`END_FLOW_WITH_FAILURE`	Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione al flusso attuale. La pagina di chiamata può gestire questa transizione con l'evento integrato `flow-failed`. Consulta anche Limite dello stack di chiamate e dello stack del flusso dell'handler.
`END_FLOW_WITH_HUMAN_ESCALATION`	Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione al flusso attuale. La pagina delle chiamate può gestire questa transizione con l'evento integrato `flow-failed-human-escalation`. Vedi anche Stack delle chiamate del gestore e limite dello stack di flusso.
`END_SESSION`	Cancella la sessione corrente e passa alla pagina speciale denominata `END_SESSION`. Il successivo input utente riavvia la sessione nella pagina iniziale del flusso di avvio predefinito.
`PREVIOUS_PAGE`	Transizione alla pagina precedente che ha generato una transizione alla pagina corrente. Lo stato della pagina precedente verrà ripristinato dopo la transizione.
`CURRENT_PAGE`	Esegui di nuovo la transizione 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 flusso

Quando una sessione passa da un flusso all'altro con target di transizione specifici, ogni flusso viene inserito nello stack dei flussi.

Stack di chiamate dell'handler

Quando una sessione viene trasferita a END_FLOW, torna alla pagina delle chiamate che ha causato una transizione al flusso completato. In questa situazione, la pila di chiamate dell'handler viene conservata. Tutti i gestori che sono stati valutati in precedenza dalla pagina delle chiamate verrà ignorato, mentre i gestori rimanenti saranno valutati in ordine.

Ad esempio:

La pagina P ha tre gestori in questo ordine: H1, H2, H3.
Viene valutato H1, ma non viene generata una transizione.
H2 viene valutato e provoca una transizione al flusso F.
Una pagina nel flusso F passa a END_FLOW.
La sessione torna alla Pagina P, che diventa di nuovo attivo con uno stato conservato.
La valutazione del gestore nella pagina P continua rispetto allo stato che ha conservato, pertanto viene valutato H3.

Limite stack di flusso

Il limite massimo dello stack di flusso è 25. Il superamento del limite massimo di stack può essere causare lo sgancio dei flussi dallo stack, con conseguenti comportamenti imprevisti quando utilizzi la transizione END_FLOW. Per evitare questi potenziali problemi, riduci al minimo il numero di transizioni da flusso a flusso precedenti alla transizione END_FLOW.

Se lo stack del flusso è vuoto, la transizione END_FLOW termina la sessione.

Imposta condizioni

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

Trova ALMENO UNA regola (OR)
Corrisponde a OGNI regola (E)
Personalizza espressione

Per praticità, puoi utilizzare le opzioni AND/OR per creare le condizioni per i valori parametro.

Puoi utilizzare l'opzione in formato libero Personalizza espressione per tutte tipi di condizioni, tra cui funzioni di sistema e costanti booleane.

Ad esempio: per impostare una condizione con 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