Alcuni prodotti e funzionalità sono in fase di rinominazione. Anche le funzionalità di playbook e flusso generativi sono in fase di migrazione a un'unica console consolidata. Consulta i dettagli.

Questa pagina è stata tradotta dall'API Cloud Translation.

Gestori di stato

Gli handler di stato, chiamati anche semplicemente handler, vengono utilizzati per controllare la conversazione creando risposte per gli utenti finali e/o passando alla 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 per consentire all'handler di avere un 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 o definite nei dati statici dell'agente o recuperate dinamicamente dal 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ò essere solo una pagina di inizio del flusso o una pagina all'interno del flusso attualmente attivo.

Esistono due tipi di gestori di stato con requisiti diversi:

Termine	Definizione
Route	I percorsi vengono chiamati quando un input utente finale corrisponde a un intent e/o viene soddisfatta una condizione relativa allo 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 sono soddisfatti, la valutazione viene superata.
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 essere nell'ambito. L'ambito dell'handler è 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 deve essere verificata una condizione
	Quando è possibile gestire un determinato evento
	Quando può verificarsi una transizione di pagina
	Quando viene fornita una risposta di adempimento statica
	Quando viene chiamato un'implementazione abilitata per webhook 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:

Percorsi applicati al flusso attivo:
- Se la pagina corrente è la pagina di inizio del flusso, sono inclusi nell'ambito.
- Se la pagina corrente non è la pagina di inizio del flusso, rientrano nell'ambito solo se hanno un requisito di intent.
I percorsi applicati 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 soddisfatti entrambi per chiamare il percorso:

Termine	Definizione
Requisito per l'intent	Un intento che deve essere associato all'input 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 alle pagine (route a livello di pagina). Ad esempio, potresti utilizzare i percorsi nelle seguenti situazioni:

X	Elemento
	Quando l'input utente finale corrisponde a un'intenzione, la corrispondenza deve attivare una risposta di adempimento statico.
	Quando l'input utente dell'utente finale corrisponde a un'intenzione, la corrispondenza deve attivare un'implementazione abilitata per i webhook per una risposta dinamica.
	Quando l'input 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 un parametro del modulo specifico, un controllo delle condizioni attiva una risposta di fulfillment statico.
	Un controllo delle condizioni impostato su `true` che forza una transizione di pagina.

Propagazione dell'intent

In genere, quando viene chiamato un percorso a causa di un intent corrispondente, l'intent viene consumato. Un'intenzione consumata non può essere associata di nuovo, a meno che un nuovo input utente finale non attivi una nuova corrispondenza dell'intenzione. Tuttavia, è possibile propagare una corrispondenza dell'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 un percorso 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 utente finale e vengono chiamati entrambi i percorsi.

La propagazione delle intenzioni è 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 di gruppo riutilizzabili all'interno del flusso o dell'intero agente.

Ad esempio, potresti volere che il flusso gestisca l'input 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. Potresti definire due percorsi con intent per gestire questi input per tutte le pagine pertinenti, ma si tratta di un lavoro molto duplicato. In alternativa, puoi definire il gruppo di route una volta e aggiungere un riferimento al gruppo in 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 gruppo principale. 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 gruppo principale. Sono riutilizzabili nell'intero agente, ma non consentono percorsi che passano a una pagina non simbolica come target.

Percorsi a livello di flusso

I percorsi a livello di flusso sono percorsi applicati a un flusso aggiungendoli alla pagina di inizio 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 di inizio del flusso.
Fai clic sul pulsante di aggiunta nell'intestazione Percorsi.
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 di inizio del flusso.
Fai clic sull'intestazione Percorsi.
Viene visualizzato 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 flusso dalla console:

Apri la pagina di inizio del flusso.
Fai clic sull'intestazione Percorsi.
Viene visualizzato il riquadro dell'elenco dei percorsi.
Fai clic sul menu dell'opzione .
Seleziona Elimina.

Route a livello di pagina

I percorsi a livello di pagina sono percorsi applicati 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 di inizio del flusso).
Fai clic sul pulsante di aggiunta nell'intestazione Percorsi.
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 di inizio del flusso).
Fai clic sull'intestazione Percorsi.
Viene visualizzato 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 di inizio del flusso).
Fai clic sull'intestazione Percorsi.
Viene visualizzato 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 eventi ai flussi (gestori eventi a livello di flusso), alle pagine (gestori eventi a livello di pagina) e ai parametri (gestori eventi a livello di parametro). Ad esempio, potresti utilizzare i gestori di eventi nelle seguenti situazioni:

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

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 in ambito per la pagina di inizio del flusso.
	Gestori con un requisito di evento nell'ambito per tutte le pagine all'interno 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.
	Gestione degli eventi personalizzati invocati dal sistema, 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 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 di inizio del flusso.
Fai clic sul pulsante Aggiungi nell'intestazione Gestione eventi.
Viene visualizzato il riquadro del gestore degli 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 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 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 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 di inizio 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 nell'intestazione Gestione eventi.
Viene visualizzato il riquadro del gestore degli 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 di inizio 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 degli eventi a livello di parametro

I gestori di eventi a livello di parametro sono gestori di eventi che vengono applicati a un parametro del modulo. Sono noti anche come gestori di richiesta di conferma. Questi gestori 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 eventi a livello di parametro dalla console:

Apri una pagina contenente i parametri del modulo.
Fai clic su un parametro.
Viene visualizzato il riquadro dei parametri.
Scorri verso il basso fino alla sezione Gestione eventi di richiesta di conferma, poi fai clic su Aggiungi gestore eventi.
Viene visualizzato il riquadro del gestore degli 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.
Viene visualizzato il riquadro dei parametri.
Scorri verso il basso fino alla sezione Gestori di eventi di richiesta di conferma.
Passa il mouse sopra un gestore eventi, quindi fai clic sul pulsante Elimina .

Eventi integrati

I seguenti eventi sono integrati e vengono richiamati da Conversational Agents (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: l'input utente finale non corrisponde a nessun'intenzione per gli addetti al trattamento che rientrano nell'ambito. Per il livello parameter: l'input 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 nell'ordine: `sys.no-match-1`, `sys.no-match-2`, ...
`sys.no-input-default`	✔	✔	✔	L'input utente finale non è stato ricevuto. Questo può essere invocato quando: Conversational Agents (Dialogflow CX) riceve un input di testo dell'utente finale vuoto. Conversational Agents (Dialogflow CX) riceve un input audio dell'utente finale vuoto o l'input non contiene alcun parlato riconosciuto. Un timeout senza parlato si verifica prima che l'input audio dell'utente finale contenga parlato riconosciuto.
`sys.no-input-[1-6]`	✔	✔	✔	Se fornisci gestori per uno di questi eventi ordinati numericamente, vengono richiamati anziché `sys.no-input-default` e nell'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 utente finale supera la lunghezza massima consentita (256 caratteri) abbinata a intent non generativi o parametri. Se non viene fornito, Conversational Agents (Dialogflow CX) tratta l'espressione dell'utente lunga come `no-match`. Per gli input audio in streaming, questo evento viene attivato solo dopo che il client ha chiuso lo stream audio.
`webhook.error`	✔	✔		La chiamata all'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 al webhook è scaduta. 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.bad-request`	✔	✔		Il webhook ha restituito 400 Bad Request. 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.rejected`	✔	✔		Il webhook ha restituito 401 Unauthorized o 403 Forbidden. 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.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`	✔	✔		La chiamata all'webhook non è riuscita perché l'URL non era 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. Consulta Destinazione transizione simbolica.`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 le attività che si verificano 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 vengono identificati semplicemente per nome. Evita di utilizzare nomi di eventi che iniziano con sys. o webhook. per evitare conflitti con gli eventi integrati.

Per invocare 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 di sessione	Interfaccia di 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 un target di transizione, la valutazione dell'elenco di gestori continua. A causa di questa regola, più adempimento possono aggiungere più messaggi alla coda di risposta.
Se viene chiamato un gestore con un target di transizione, la valutazione dell'elenco di gestori termina.
Se viene chiamato un gestore con il completamento e il completamento genera un errore webhook:
- Se per l'handler è definito un target di transizione, il webhook non genera alcun messaggio di errore.
- Se un gestore eventi è nell'ambito dell'evento, lo gestisce e la valutazione dell'elenco di gestori termina.
- Se non è presente alcun gestore eventi per l'evento, il webhook non va a buon fine in modo silenzioso.
Quando un requisito dell'intent è soddisfatto, l'intent viene utilizzato, pertanto può essere chiamato solo il primo gestore percorso trovato per l'intent (consulta la sezione Propagazione dell'intent per le eccezioni).
Quando un requisito della condizione è soddisfatto, la condizione non viene utilizzata, pertanto è possibile chiamare più percorsi con la condizione.
Quando un requisito relativo a un evento è soddisfatto, l'evento viene utilizzato, pertanto può essere chiamato solo il primo gestore di eventi trovato per l'evento.
La pila di chiamate dell'handler può influire sull'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: 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: le route applicate al flusso attivo, nell'ordine specificato.
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 richieste ripetute), nell'ordine specificato.
2. A livello di pagina: i gestori di eventi applicati alla pagina corrente, nell'ordine specificato.
3. A livello di flusso: gestitori di eventi applicati al flusso attivo, nell'ordine specificato.

Destinazioni di transizione simboliche

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

Destinazione della transizione simbolica	Descrizione
`START_PAGE`	Passa alla pagina iniziale del flusso attivo con nome simile.
`END_FLOW`	Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione al flusso corrente. Consulta anche Limite dello stack di chiamate e dello stack del flusso dell'handler.
`END_FLOW_WITH_CANCELLATION`	Termina il flusso attualmente attivo e torna alla pagina che ha causato una transizione al flusso corrente. 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 corrente. 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 corrente. La pagina di chiamata può gestire questa transizione con l'evento integrato `flow-failed-human-escalation`. Consulta anche Limite dello stack di chiamate e dello stack del flusso dell'handler.
`END_SESSION`	Cancella la sessione corrente e passa alla pagina speciale denominata `END_SESSION`. Il successivo input utente riavvierà la sessione nella 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`	Torna alla pagina corrente. Questa opzione può essere utile se vuoi che l'agente ripeta qualcosa.

Stack di chiamate dell'handler e limite dello stack del 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 passa a END_FLOW, viene visualizzata nuovamente la pagina di chiamata che ha causato la transizione al flusso completato. In questa situazione, la pila di chiamate dell'handler viene conservata. Tutti i gestori valutati in precedenza dalla pagina di chiamata verranno ignorati e gli altri gestori verranno valutati in ordine.

Ad esempio:

La pagina P ha tre gestori in questo ordine: H1, H2, H3.
H1 viene valutato, ma non causa 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 attiva con uno stato preservato.
La valutazione dell'handler nella pagina P continua dallo stato che ha conservato, quindi H3 viene valutato.

Limite della serie di attività

Il limite massimo della pila di flussi è 25. Il superamento del limite massimo dello stack può provocare l'estrazione dei flussi dallo stack, con conseguente comportamento imprevisto quando si utilizza 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, fornisci le regole di condizione con una delle tre opzioni logiche:

Corrispondenza con ALMENO UNA regola (OR)
Corrisponde a OGNI regola (AND)
Personalizza l'espressione

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

Puoi utilizzare l'opzione di modulo libero Personalizza espressione per tutti i tipi di condizioni, tra cui le funzioni di sistema e le 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