Hierarchical advanced settings for agent/flow/page/fulfillment/parameter. Settings exposed at lower level overrides the settings exposed at higher level. Overriding occurs at the sub-setting level. For example, the playback_interruption_settings at fulfillment level only overrides the playback_interruption_settings at the agent level, leaving other settings at the agent level unchanged. DTMF settings does not override each other. DTMF settings set at different levels define DTMF detections running in parallel. Hierarchy: Agent->Flow->Page->Fulfillment/Parameter.
Agents are best described as Natural Language Understanding (NLU) modules that transform user requests into actionable data. You can include agents in your app, product, or service to determine user intent and respond to the user in a natural way. After you create an agent, you can add Intents, Entity Types, Flows, Fulfillments, Webhooks, TransitionRouteGroups and so on to manage the conversation flows.
Configuration of the barge-in behavior. Barge-in instructs the API to return a detected utterance at a proper time while the client is playing back the response audio from a previous request. When the client sees the utterance, it should stop the playback and immediately get ready for receiving the responses for the current request. The barge-in handling requires the client to start streaming audio input as soon as it starts playing back the audio from the previous response. The playback is modeled into two phases: * No barge-in phase: which goes first and during which speech detection should not be carried out. * Barge-in phase: which follows the no barge-in phase and during which the API starts speech detection and may inform the client that an utterance has been detected. Note that no-speech event is not expected in this phase. The client provides this configuration in terms of the durations of those two phases. The durations are measured in terms of the audio length from the the start of the input audio. No-speech event is a response with END_OF_UTTERANCE without any transcript following up.
Boost specification to boost certain documents. A copy of google.cloud.discoveryengine.v1main.BoostSpec, field documentation is available at https://cloud.google.com/generative-ai-app-builder/docs/reference/rest/v1alpha/BoostSpec
Data store connection feature output signals. Might be only partially field if processing stop before the final answer. Reasons for this can be, but are not limited to: empty UCS search results, positive RAI check outcome, grounding failure, …
Represents a deployment in an environment. A deployment happens when a flow version configured to be active in the environment. You can configure running pre-deployment steps, e.g. running validation test cases, experiment auto-rollout, etc.
Entities are extracted from user input and represent parameters that are meaningful to your application. For example, a date range, a proper name such as a geographic location or landmark, and so on. Entities represent actionable data for your application. When you define an entity, you can also include synonyms that all map to that entity. For example, “soft drink”, “soda”, “pop”, and so on. There are three types of entities: * System - entities that are defined by the Dialogflow API for common data types such as date, time, currency, and so on. A system entity is represented by the EntityType type. * Custom - entities that are defined by you that represent actionable data that is meaningful to your application. For example, you could define a pizza.sauce entity for red or white pizza sauce, a pizza.cheese entity for the different types of cheese on a pizza, a pizza.topping entity for different toppings, and so on. A custom entity is represented by the EntityType type. * User - entities that are built for an individual user such as favorites, preferences, playlists, and so on. A user entity is represented by the SessionEntityType type. For more information about entity types, see the Dialogflow documentation.
Represents an environment for an agent. You can create multiple versions of your agent and publish them to separate environments. When you edit an agent, you are editing the draft agent. At any point, you can save the draft agent as an agent version, which is an immutable snapshot of your agent. When you save the draft agent, it is published to the default environment. When you create agent versions, you can publish them to custom environments. You can create a variety of custom environments for testing, development, production, etc.
An event handler specifies an event that can be handled during a session. When the specified event happens, the following actions are taken in order: * If there is a trigger_fulfillment associated with the event, it will be called. * If there is a target_page associated with the event, the session will transition into the specified page. * If there is a target_flow associated with the event, the session will transition into the specified flow.
Flows represents the conversation flows when you build your chatbot agent. A flow consists of many pages connected by the transition routes. Conversations always start with the built-in Start Flow (with an all-0 ID). Transition routes can direct the conversation session from the current flow (parent flow) to another flow (sub flow). When the sub flow is finished, Dialogflow will bring the session back to the parent flow, where the sub flow is started. Usually, when a transition route is followed by a matched intent, the intent will be “consumed”. This means the intent won’t activate more transition routes. However, when the followed transition route moves the conversation session into a different flow, the matched intent can be carried over and to be consumed in the target flow.
A form is a data model that groups related parameters that can be collected from the user. The process in which the agent prompts the user and collects parameter values from the user is called form filling. A form can be added to a page. When form filling is done, the filled parameters will be written to the session.
A fulfillment can do one or more of the following actions at the same time: * Generate rich message responses. * Set parameter values. * Call the webhook. Fulfillments can be called at various stages in the Page or Form lifecycle. For example, when a DetectIntentRequest drives a session to enter a new page, the page’s entry fulfillment can add a static response to the QueryResult in the returning DetectIntentResponse, call the webhook (for example, to load user data from a database), or both.
Settings for knowledge connector. These parameters are used for LLM prompt like “You are . You are a helpful and verbose at , . Your task is to help humans on “.
Generators contain prompt to be sent to the LLM model to generate text. The prompt can contain parameters which will be resolved before calling the model. It can optionally contain banned phrases to ensure the model responses are safe.
An intent represents a user’s intent to interact with a conversational agent. You can provide information for the Dialogflow API to use to match user input to an intent by adding training phrases (i.e., examples of user input) to your intent.
The Knowledge Connector settings for this page or flow. This includes information such as the attached Knowledge Bases, and the way to execute fulfillment.
A Dialogflow CX conversation (session) can be described and visualized as a state machine. The states of a CX session are represented by pages. For each flow, you define many pages, where your combined pages can handle a complete conversation on the topics the flow is designed for. At any given moment, exactly one page is the current page, the current page is considered active, and the flow associated with that page is considered active. Every flow has a special start page. When a flow initially becomes active, the start page page becomes the current page. For each conversational turn, the current page will either stay the same or transition to another page. You configure each page to collect information from the end-user that is relevant for the conversational state represented by the page. For more information, see the Page guide.
Represents the query input. It can contain one of: 1. A conversational query in the form of text. 2. An intent query that specifies which intent to trigger. 3. Natural language speech audio to be processed. 4. An event to be triggered. 5. DTMF digits to invoke an intent and fill in parameter value. 6. The results of a tool executed by the client.
Represents a response message that can be returned by a conversational agent. Response messages are also used for output audio synthesis. The approach is as follows: * If at least one OutputAudioText response is present, then all OutputAudioText responses are linearly concatenated, and the result is used for output audio synthesis. * If the OutputAudioText responses are a mixture of text and SSML, then the concatenated result is treated as SSML; otherwise, the result is treated as either text or SSML as appropriate. The agent designer should ideally use either text or SSML consistently throughout the bot design. * Otherwise, all Text responses are linearly concatenated, and the result is used for output audio synthesis. This approach allows for more sophisticated user experience scenarios, where the text displayed to the user may differ from what is heard.
Indicates that the conversation succeeded, i.e., the bot handled the issue that the customer talked to it about. Dialogflow only uses this to determine which conversations should be counted as successful and doesn’t process the metadata in this message in any way. Note that Dialogflow also considers conversations that get to the conversation end page as successful even if they don’t return ConversationSuccess. You may set this, for example: * In the entry_fulfillment of a Page if entering the page indicates that the conversation succeeded. * In a webhook response when you determine that you handled the customer issue.
Indicates that interaction with the Dialogflow agent has ended. This message is generated by Dialogflow only and not supposed to be defined by the user.
Represents info card response. If the response contains generative knowledge prediction, Dialogflow will return a payload with Infobot Messenger compatible info card. Otherwise, the info card response is skipped.
Indicates that the conversation should be handed off to a live agent. Dialogflow only uses this to determine which conversations were handed off to a human agent for measurement purposes. What else to do with this signal is up to you and your handoff procedures. You may set this, for example: * In the entry_fulfillment of a Page if entering the page indicates something went extremely wrong in the conversation. * In a webhook response when you determine that the customer issue can only be handled by a human.
Represents an audio message that is composed of both segments synthesized from the Dialogflow agent prompts and ones hosted externally at the specified URIs. The external URIs are specified via play_audio. This message is generated by Dialogflow only and not supposed to be defined by the user.
Represents the settings related to security issues, such as data redaction and data retention. It may take hours for updates on the settings to propagate to all the related components and take effect.
The result of sentiment analysis. Sentiment analysis inspects user input and identifies the prevailing subjective opinion, especially to determine a user’s attitude as positive, negative, or neutral.
Session entity types are referred to as User entity types and are entities that are built for an individual user such as favorites, preferences, playlists, and so on. You can redefine a session entity type at the session level to extend or replace a custom entity type at the user session level (we refer to the entity types defined at the agent level as “custom entity types”). Note: session entity types apply to all queries, regardless of the language. For more information about entity types, see the Dialogflow documentation.
Transition coverage represents the percentage of all possible page transitions (page-level transition routes and event handlers, excluding transition route groups) present within any of a parent’s test cases.
A transition route specifies a intent that can be matched and/or a data condition that can be evaluated during a session. When a specified transition is matched, the following actions are taken in order: * If there is a trigger_fulfillment associated with the transition, it will be called. * If there is a target_page associated with the transition, the session will transition into the specified page. * If there is a target_flow associated with the transition, the session will transition into the specified flow.
Transition route group coverage represents the percentage of all possible transition routes present within any of a parent’s test cases. The results are grouped by the transition route group.
Webhooks host the developer’s business logic. During a session, webhooks allow the developer to use the data extracted by Dialogflow’s natural language processing to generate dynamic responses, validate collected data, or trigger actions on the backend.
A generic empty message that you can re-use to avoid defining duplicated empty messages in your APIs. A typical example is to use it as the request or the response type of an API method. For instance: service Foo { rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty); }
The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.
An object that represents a latitude/longitude pair. This is expressed as a pair of doubles to represent degrees latitude and degrees longitude. Unless specified otherwise, this object must conform to the WGS84 standard. Values must be within normalized ranges.
Creates an Environment in the specified Agent. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: An empty Struct message - response: Environment
Deploys a flow to the specified Environment. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: DeployFlowMetadata - response: DeployFlowResponse
Updates the specified Environment. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: An empty Struct message - response: Environment
Kicks off a continuous test under the specified Environment. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: RunContinuousTestMetadata - response: RunContinuousTestResponse
Processes a natural language query and returns structured, actionable data as a result. This method is not idempotent, because it may cause session entity types to be updated, which in turn might affect results of future queries. Note: Always use agent versions for production traffic. See Versions and environments.
Fulfills a matched intent returned by MatchIntent. Must be called after MatchIntent, with input from MatchIntentResponse. Otherwise, the behavior is undefined.
Processes a natural language query and returns structured, actionable data as a result through server-side streaming. Server-side streaming allows Dialogflow to send partial responses earlier in a single request.
Exports the specified agent to a binary file. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: An empty Struct message - response: ExportAgentResponse
Exports the specified flow to a binary file. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: An empty Struct message - response: ExportFlowResponse Note that resources (e.g. intents, entities, webhooks) that the flow references will also be exported.
Imports the specified flow to the specified agent from a binary file. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: An empty Struct message - response: ImportFlowResponse Note: You should always train a flow prior to sending it queries. See the training documentation.
Trains the specified flow. Note that only the flow in ‘draft’ environment is trained. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: An empty Struct message - response: An Empty message Note: You should always train a flow prior to sending it queries. See the training documentation.
Creates an TransitionRouteGroup in the specified flow. Note: You should always train a flow prior to sending it queries. See the training documentation.
Validates the specified flow and creates or updates validation results. Please call this API after the training is completed to get the complete validation results.
Creates a Version in the specified Flow. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: CreateVersionOperationMetadata - response: Version
Loads resources in the specified version to the draft flow. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: An empty Struct message - response: An Empty message
Exports the selected intents. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: ExportIntentsMetadata - response: ExportIntentsResponse
Imports the specified intents into the agent. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: ImportIntentsMetadata - response: ImportIntentsResponse
Restores the specified agent from a binary file. Replaces the current agent with a new one. Note that all existing resources in agent (e.g. intents, entity types, flows) will be removed. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: An empty Struct message - response: An Empty message Note: You should always train flows prior to sending them queries. See the training documentation.
Processes a natural language query and returns structured, actionable data as a result. This method is not idempotent, because it may cause session entity types to be updated, which in turn might affect results of future queries. Note: Always use agent versions for production traffic. See Versions and environments.
Fulfills a matched intent returned by MatchIntent. Must be called after MatchIntent, with input from MatchIntentResponse. Otherwise, the behavior is undefined.
Processes a natural language query and returns structured, actionable data as a result through server-side streaming. Server-side streaming allows Dialogflow to send partial responses earlier in a single request.
Kicks off a batch run of test cases. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: BatchRunTestCasesMetadata - response: BatchRunTestCasesResponse
Exports the test cases under the agent to a Cloud Storage bucket or a local file. Filter can be applied to export a subset of test cases. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: ExportTestCasesMetadata - response: ExportTestCasesResponse
Imports the test cases from a Cloud Storage bucket or a local file. It always creates new test cases and won’t overwrite any existing ones. The provided ID in the imported test case is neglected. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: ImportTestCasesMetadata - response: ImportTestCasesResponse
Kicks off a test case run. This method is a long-running operation. The returned Operation type has the following method-specific fields: - metadata: RunTestCaseMetadata - response: RunTestCaseResponse
Creates an TransitionRouteGroup in the specified flow. Note: You should always train a flow prior to sending it queries. See the training documentation.
Validates the specified agent and creates or updates validation results. The agent in draft version is validated. Please call this API after the training is completed to get the complete validation results.
Starts asynchronous cancellation on a long-running operation. The server makes a best effort to cancel the operation, but success is not guaranteed. If the server doesn’t support this method, it returns google.rpc.Code.UNIMPLEMENTED. Clients can use Operations.GetOperation or other methods to check whether the cancellation succeeded or whether the operation completed despite cancellation. On successful cancellation, the operation is not deleted; instead, it becomes an operation with an Operation.error value with a google.rpc.Status.code of 1, corresponding to Code.CANCELLED.
Gets the latest state of a long-running operation. Clients can use this method to poll the operation result at intervals as recommended by the API service.
Starts asynchronous cancellation on a long-running operation. The server makes a best effort to cancel the operation, but success is not guaranteed. If the server doesn’t support this method, it returns google.rpc.Code.UNIMPLEMENTED. Clients can use Operations.GetOperation or other methods to check whether the cancellation succeeded or whether the operation completed despite cancellation. On successful cancellation, the operation is not deleted; instead, it becomes an operation with an Operation.error value with a google.rpc.Status.code of 1, corresponding to Code.CANCELLED.
Gets the latest state of a long-running operation. Clients can use this method to poll the operation result at intervals as recommended by the API service.