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

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

Termine	Definizione
Requisiti del gestore	Questi sono i requisiti che devono essere soddisfatti affinché l'handler abbia un effetto sulla sessione. Si dice che un gestore viene chiamato quando soddisfa i suoi requisiti e influisce sulla sessione in qualche modo.
Evasione dell'handler	Se viene chiamato un gestore, un fulfillment facoltativo viene utilizzato per creare risposte per gli utenti finali. Queste risposte sono definite nei dati statici dell'agente o recuperate dinamicamente dal tuo servizio webhook.
Destinazione della transizione del gestore	Se viene chiamato un gestore, viene utilizzato un target di transizione facoltativo 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 diversi:

Termine	Definizione
Route	Le route vengono chiamate quando l'input di un utente finale corrisponde a un intent e/o a una condizione sullo stato della sessione. Una route con un requisito di intent è chiamata anche route di intent. Un percorso con un solo requisito di condizione è chiamato anche percorso di condizione.
Gestori di eventi	I gestori di eventi vengono chiamati quando viene richiamato un evento. Alcuni eventi integrati vengono attivati quando vengono ricevuti input utente imprevisti dell'utente finale o quando si verifica un errore webhook. Puoi anche definire eventi personalizzati che vengono richiamati quando succede 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 è determinato dal fatto che un gestore venga applicato a un flusso, a una pagina o a un parametro del 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 del modulo associato.
2. Valutazione	Ogni gestore nell'ambito viene valutato in ordine. Se i requisiti di un gestore vengono soddisfatti, la valutazione viene superata.
3. Chiamata	Se un gestore è nell'ambito e supera la valutazione, viene chiamato. Viene chiamato qualsiasi completamento associato e viene applicato alla sessione qualsiasi target di transizione associato.

Ambito

Affinché un gestore venga valutato, deve rientrare nell'ambito. L'ambito del gestore è uno strumento importante ed efficace che ti aiuta a controllare la conversazione. Controllando l'ambito di un gestore, puoi controllare:

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

L'ambito è determinato dal fatto che un gestore venga applicato a un flusso, una pagina o un parametro del 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 del modulo associato.

Le regole di definizione dell'ambito dettagliate sono le seguenti:

Route applicate al flusso attivo:
- Se la pagina corrente è la pagina iniziale del flusso, è inclusa nell'ambito.
- Se la pagina corrente non è la pagina iniziale del flusso, sono incluse nell'ambito solo se hanno un requisito di intent.
I percorsi applicati alla pagina corrente sono inclusi nell'ambito.
I gestori di eventi applicati al flusso attivo sono inclusi nell'ambito.
I gestori di eventi applicati alla pagina corrente sono inclusi nell'ambito.
I gestori di eventi applicati a un parametro del modulo che l'agente sta attualmente tentando di compilare sono inclusi nell'ambito.

Route

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

Termine	Definizione
Requisito di intent	Un intent che deve corrispondere all'input utente finale per il turno di conversazione corrente. Quando una route ha un requisito di intent, viene chiamata route di intent.
Requisito di condizione	Una condizione che deve essere soddisfatta. Quando una route ha un requisito di condizione, viene chiamata route di condizione.

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

X	Elemento
	Quando l'input utente finale corrisponde a un intent, la corrispondenza deve attivare una risposta di fulfillment statico.
	Quando l'input utente finale corrisponde a un intent, la corrispondenza deve attivare un fulfillment abilitato per 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 un controllo della condizione attiva una risposta di fulfillment statico.
	Un controllo delle condizioni impostato su `true` che forza una transizione di pagina.

Propagazione dell'intent

Normalmente, quando viene chiamata una route a causa di un intent corrispondente, l'intent viene utilizzato. Un intent utilizzato non può essere abbinato di nuovo, a meno che un nuovoinput utentee finale non attivi una nuova corrispondenza dell'intent. Tuttavia, è possibile propagare una corrispondenza di intent da un flusso a un 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 richiede anche intent I1.

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

La propagazione degli intent è utile per:

X	Elemento
	Modifica 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 ingresso per la pagina iniziale di un flusso (il percorso del flusso di destinazione della transizione ha un fulfillment).

Gruppi di route

Quando crei un agente, potresti notare che molte pagine hanno un insieme comune di route. 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 voler che il flusso gestisca l'input utente finale come "Voglio aggiungere un condimento alla mia pizza" e "Voglio cambiare le dimensioni della mia bevanda". Questi input devono essere gestiti quando è attiva una delle più pagine del flusso. Potresti definire due route con intent per gestire questi input per tutte le pagine pertinenti, ma questo comporta molto lavoro duplicato. In alternativa, puoi definire il gruppo di route una sola 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 del gruppo di route create con un flusso come elemento 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 elemento principale. Sono riutilizzabili all'interno dell'intero agente, ma non consentono route che passano a una pagina non simbolica come destinazione.

Route a livello di flusso

I percorsi a livello di flusso sono percorsi applicati a un flusso aggiungendoli 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.
	Gestori con un requisito di intent nell'ambito di tutte le pagine del flusso.

Per creare route a livello di flusso dalla console:

Apri la pagina iniziale del flusso.
Fai clic sul pulsante Aggiungi nell'intestazione Percorsi.
Viene visualizzato il riquadro di modifica dell'itinerario.
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.
Viene visualizzato il riquadro dell'elenco dei percorsi.
Trascina gli itinerari nell'ordine che preferisci. In alternativa, fai clic sul menu opzioni, quindi seleziona Sposta in.

Per eliminare le route a livello di flusso dalla console:

Apri la pagina iniziale 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

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 nell'ambito quando sono attive pagine specifiche.

Per creare route a livello di pagina dalla console:

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

Per riordinare le route a livello di pagina dalla console:

Apri la pagina (non la pagina iniziale del flusso).
Fai clic sull'intestazione Percorsi.
Viene visualizzato il riquadro dell'elenco dei percorsi.
Trascina gli itinerari nell'ordine che preferisci. In alternativa, fai clic sul menu opzioni, quindi 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 Percorsi.
Viene visualizzato il riquadro dell'elenco dei percorsi.
Fai clic sul menu dell'opzione .
Seleziona Elimina.

Gestori di eventi

Per poter essere chiamati, i gestori di eventi devono soddisfare un requisito:

Termine	Definizione
Requisito per l'evento	Un evento che deve essere richiamato. Gli eventi sono identificati dal nome. Alcuni eventi integrati vengono richiamati quando vengono ricevuti input imprevisti dell'utente finale o quando si verifica un errore webhook. Puoi anche definire eventi personalizzati che richiami quando succede qualcosa al di fuori della conversazione.

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

X	Elemento
	Quando l'input utente finale non corrisponde ad alcun intent, un gestore di eventi nessuna corrispondenza fornisce una risposta static fulfillment specifica.
	Un timer scade nel tuo sistema e vuoi fornire informazioni sul promemoria all'utente finale con una risposta static fulfillment 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 nell'ambito della pagina di avvio del flusso.
	Gestori con un requisito di evento nell'ambito di tutte le pagine del flusso.
	Gestione dell'input imprevisto dell'utente finale, condiviso da tutte le pagine di un flusso.
	Gestione degli errori webhook, condivisi da tutte le pagine di un flusso.
	Gestione degli eventi personalizzati richiamati dal sistema, condivisi da tutte le pagine di un flusso.

Ogni flusso ha gestori di eventi per gli 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 Gestori 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 iniziale del flusso.
Fai clic sull'intestazione Gestori di eventi.
Viene visualizzato il riquadro dell'elenco dei gestori di eventi.
Passa il mouse sopra un gestore di eventi, poi 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 dell'input imprevisto dell'utente finale, specifico per una pagina.
	Gestione degli errori webhook, specifici di una pagina.
	Gestione di eventi personalizzati richiamati 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 Gestori di eventi, fai clic su Aggiungi gestore di stato, seleziona Gestori di eventi, poi fai clic su Applica.
Fai clic sul pulsante Aggiungi nell'intestazione Gestori 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 Gestori di eventi.
Viene visualizzato il riquadro dell'elenco dei gestori di eventi.
Passa il mouse sopra un gestore di eventi, poi fai clic sul pulsante Elimina .

Gestori 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 richieste. Questi gestori di eventi non consentono eventi personalizzati, in quanto sono specificamente destinati a gestire l&#39input utentee 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:

Apri una pagina che contiene 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 riautorizzazione, poi fai clic su Aggiungi gestore di 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 che contiene 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 riautorizzazione.
Passa il mouse sopra un gestore di eventi, poi fai clic sul pulsante Elimina .

Eventi integrati

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

Nome evento	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 inclusi nell'ambito. Per il livello parametro: 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 al posto di `sys.no-match-default` e in ordine: `sys.no-match-1`, `sys.no-match-2`, ...
`sys.no-input-default`	✔	✔	✔	L'input utente finale non è stato ricevuto. Può essere richiamato quando: Dialogflow CX riceve un input di testo vuoto dell'utente finale. Dialogflow CX riceve un input audio vuoto dell'utente finale o l'input non contiene alcun parlato riconosciuto. Si verifica un timeout di assenza di voce prima che l'input audio dell'utente finale contenga un discorso riconosciuto.
`sys.no-input-[1-6]`	✔	✔	✔	Se fornisci gestori per uno di questi eventi ordinati numericamente, vengono richiamati al posto di `sys.no-input-default` e in ordine: `sys.no-input-1`, `sys.no-input-2`, ...
`sys.invalid-parameter`			✔	Richiamato 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) corrispondente a intent non generativi o parametri. Se non viene fornita, Dialogflow CX considera l'espressione dell'utente lunga 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 corrisponda al codice di errore webhook, 2) se non è impostata una destinazione di transizione nella route originale che ha chiamato l'intent con il webhook non riuscito. Per i dettagli, consulta la sezione Ordine di valutazione.
`webhook.error.timeout`	✔	✔		Timeout della chiamata webhook. Un evento webhook verrà richiamato solo se non è impostata alcuna destinazione di transizione nella route originale che ha chiamato l'intent con il webhook non riuscito. Per i dettagli, consulta la sezione Ordine di valutazione.
`webhook.error.bad-request`	✔	✔		Il webhook ha restituito 400 Bad Request. Un evento webhook verrà richiamato solo se non è impostata alcuna destinazione di transizione nella route originale che ha chiamato l'intent con il webhook non riuscito. Per i dettagli, consulta la sezione Ordine di valutazione.
`webhook.error.rejected`	✔	✔		Il webhook ha restituito 401 Unauthorized o 403 Forbidden. Un evento webhook verrà richiamato solo se non è impostata alcuna destinazione di transizione nella route originale che ha chiamato l'intent con il webhook non riuscito. Per i dettagli, consulta la sezione Ordine di valutazione.
`webhook.error.unavailable`	✔	✔		Il webhook ha restituito 503 Service Unavailable. Un evento webhook verrà richiamato solo se non è impostata alcuna destinazione di transizione nella route originale che ha chiamato l'intent con il webhook non riuscito. Per i dettagli, consulta la sezione Ordine di valutazione.
`webhook.error.not-found`	✔	✔		La chiamata webhook non è riuscita perché l'URL webhook non era raggiungibile. Un evento webhook verrà richiamato solo se non è impostata alcuna destinazione di transizione nella route originale che ha chiamato l'intent con il webhook non riuscito. Per i 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 la `END_FLOW_WITH_CANCELLATION` transizione simbolica di destinazione.
`flow-failed`	✔	✔		Questo flusso non è riuscito a completare l'attività specificata. Questo evento viene attivato dalla pagina Termina flusso con errore. Vedi la `END_FLOW_WITH_FAILURE` transizione simbolica di destinazione.
`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 operatore, vedi la `END_FLOW_WITH_HUMAN_ESCALATION` transizione simbolica di destinazione.

Eventi personalizzati

Puoi creare eventi e gestori di eventi personalizzati. Gli eventi personalizzati vengono utilizzati per gestire ciò che accade 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. Per evitare conflitti con gli eventi integrati, ti consigliamo di non utilizzare nomi di eventi che iniziano con sys. o webhook..

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 alla sessione:

Protocollo	V3	V3beta1
REST	Risorsa sessione	Risorsa sessione
RPC	Interfaccia della sessione	Interfaccia della 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:

Vengono valutati solo i gestori nell'ambito.
Possono essere chiamati solo i gestori i cui requisiti sono soddisfatti.
Se viene chiamato un gestore senza una destinazione di transizione, continua la valutazione dell'elenco dei gestori. A causa di questa regola, più evasione possono aggiungere più messaggi alla coda delle risposte.
Se viene chiamato un gestore con una destinazione di transizione, la valutazione dell'elenco dei gestori termina.
Se viene chiamato un gestore con fulfillment e il fulfillment genera un errore webhook:
- Se il gestore ha una destinazione di transizione definita, il webhook non riesce in modo silenzioso.
- Se un gestore eventi è nell'ambito dell'evento, gestisce l'evento e la valutazione dell'elenco dei gestori termina.
- Se nessun gestore di eventi è nell'ambito dell'evento, il webhook non va a buon fine.
Quando un requisito di intent viene soddisfatto, l'intent viene utilizzato, quindi può essere chiamato solo il primo gestore di route trovato per l'intent (vedi propagazione dell'intent per le eccezioni).
Quando un requisito di condizione viene soddisfatto, la condizione non viene utilizzata, quindi è possibile chiamare più route con la condizione.
Quando un requisito dell'evento viene soddisfatto, l'evento viene utilizzato, quindi può essere chiamato solo il primo gestore eventi trovato per l'evento.
Lo stack di chiamate del gestore può influire sull'ordine di valutazione.

La valutazione si suddivide in tre fasi:

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

Target di transizione simbolica	Descrizione
`START_PAGE`	Transizione alla pagina iniziale del flusso attivo con lo stesso nome.
`END_FLOW`	Termina il flusso attualmente attivo e torna alla pagina che ha causato la transizione al flusso corrente. Vedi anche Limite dello stack di chiamate del gestore e dello stack di flusso.
`END_FLOW_WITH_CANCELLATION`	Termina il flusso attualmente attivo e torna alla pagina che ha causato la transizione al flusso corrente. La pagina chiamante può gestire questa transizione con l'evento integrato `flow-cancelled`. Vedi anche Limite dello stack di chiamate del gestore e dello stack di flusso.
`END_FLOW_WITH_FAILURE`	Termina il flusso attualmente attivo e torna alla pagina che ha causato la transizione al flusso corrente. La pagina chiamante può gestire questa transizione con l'evento integrato `flow-failed`. Vedi anche Limite dello stack di chiamate del gestore e dello stack di flusso.
`END_FLOW_WITH_HUMAN_ESCALATION`	Termina il flusso attualmente attivo e torna alla pagina che ha causato la transizione al flusso corrente. La pagina chiamante può gestire questa transizione con l'evento integrato `flow-failed-human-escalation`. Vedi anche Limite dello stack di chiamate del gestore e dello stack di flusso.
`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`	Passa alla pagina precedente che ha causato una transizione alla pagina attuale. Lo stato della pagina precedente verrà ripristinato dopo la transizione.
`CURRENT_PAGE`	Esegui di nuovo la transizione alla pagina corrente. Questa opzione 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 del flusso.

Stack di chiamate del gestore

Quando una sessione passa a END_FLOW, torna alla pagina di chiamata che ha causato una transizione al flusso completato. In questa situazione, lo stack di chiamate del gestore viene conservato. Tutti i gestori valutati in precedenza dalla pagina chiamante verranno ignorati e i gestori rimanenti 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 causa 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 del gestore nella pagina P continua dallo stato che ha conservato, quindi viene valutato H3.

Limite dello stack di flussi

Il limite massimo dello stack di flussi è 25. Il superamento del limite massimo dello stack può causare 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 un flusso all'altro che precedono la transizione END_FLOW.

Se lo stack di flussi è 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 TUTTE le regole (AND)
Personalizzare 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 Personalizza espressione in formato libero per tutti i tipi di condizioni, incluse le funzioni di sistema e le costanti booleane.

Ad esempio, per impostare una condizione che ha il 10% di probabilità 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