Cloud / Google Cloud Dialogflow CX (Customer Experience) Interview questions

Dialogflow CX is Google Cloud's conversational AI service for building chat and voice agents that handle long, multi-turn conversations. It models a conversation as a state machine made of flows and pages, so you always know exactly where the user is in the dialog.

Google now surfaces it inside the Conversational Agents console, which adds generative playbooks and data stores next to the classic flow builder. Agents created in any of the consoles use the same Dialogflow API, so existing CX agents keep working.

Typical uses are contact-center virtual agents, IVR replacement and customer-support bots on web or messaging channels.

A CX agent is assembled from a small set of resources. The deterministic core is flows, pages, intents, entity types, routes, fulfillment and webhooks. The generative layer adds playbooks, tools, data stores and generators.

A flow is a self-contained part of the conversation, such as billing, order tracking or account recovery. It owns a set of pages, flow-level routes and its own NLU settings, including the classification threshold.

Every agent has a Default Start Flow. You add more flows as the agent grows so each topic stays small and readable.

Flows are also the unit of versioning. You can snapshot and deploy one flow without touching the others, which lets separate teams own separate topics.

A page represents one state of the conversation, for example "Collect order ID" or "Confirm address". At any moment the user is on exactly one active page within a flow.

Each page can hold entry fulfillment (what the agent says when the page becomes active), a form of parameters to collect, and routes and event handlers that decide where to go next.

You move between pages through transition targets defined on routes.

A page named after the user's goal, such as "Collect delivery date", is much easier to follow in the flow visualization than a generic name. If one page piles up many routes, it is usually doing two jobs and should be split.

An intent captures what the user wants, such as order.status or cancel.subscription. It is defined mainly by a set of training phrases and, optionally, parameters annotated inside them.

Intents are agent-level resources, but they only take part in matching when a route in the current scope references them. The same intent can therefore behave differently on different pages.

Keep intents about user goals, not about pages. Small shared intents like "confirm" and "decline" can be reused on many routes, while refund.request captures the real business ask. A match returns a confidence score you can inspect in the Simulator.

Training phrases are example sentences that teach the NLU model how users express an intent. "Where is my order", "track my package" and "has my parcel shipped" could all belong to one intent.

Words that carry data, like an order number or a city, are annotated as parameters and linked to an entity type. Good sets mix short and long wording and include phrases with and without parameters.

Real traffic is the best source of new phrases. After launch, review utterances that ended in no-match and add the good ones to the right intent. Avoid phrases that differ by only one word, because they add little new signal.

An entity type tells the agent how to pull structured values out of free text, such as dates, numbers, cities or your own product codes. The extracted value becomes a typed parameter.

There are system entity types that Google provides (for example @sys.date and @sys.number) and custom entity types you define. Entity types are used in intent parameters and in page form parameters.

Entity types can be marked for redaction, so sensitive values such as card numbers are masked in logs. A parameter can use @sys.any to capture free text, but it matches almost anything, so prefer a specific type whenever one fits.

A custom entity type comes in three kinds, and the kind decides how values are matched.

Options like auto expansion and fuzzy extraction can widen matching when users do not use the exact listed words.

The Default Start Flow is the flow every agent is created with. Its Start page is where each new session begins.

It ships with a route for the Default Welcome Intent, which greets the user. Many teams turn the Start page into a router: intent routes there send the user to other flows such as billing or orders.

Keep the Start page small: the greeting and the top-level routes, with the detail pushed into flows. Special targets like End Session and End Flow are available from routes to finish the conversation or return to a calling flow.

State handlers decide what the agent does next. They live on pages, flows and route groups.

Each handler can run fulfillment and then move to a transition target.

Handlers are checked at the current page, the route groups attached to it, and the flow. A handler placed on the flow applies to every page in it, which suits flow-wide behavior such as "start over".

Fulfillment is what the agent does in response to something happening. It can send static messages or custom payloads, set parameter values, give conditional responses, and call a webhook.

You can attach fulfillment to a page's entry, to routes, to form parameters and to event handlers, so responses are placed exactly where they are needed.

Fulfillment can also be conditional, for example a different greeting when $session.params.is_member = true. Custom payloads let you send channel-specific content, and parameter presets let you set a value before the agent moves on.

A session parameter is a value stored for the length of one conversation. It can be set by a matched intent, a form, fulfillment or a webhook, and read anywhere in that session with $session.params.name.

The session ends when your code or the agent ends it, or after a period of inactivity (30 minutes by default). After that the stored values are gone.

Parameters captured by a matched intent are copied into the session, so later pages can use them. If the user supplies the same slot again, the newer value replaces the old one. Setting a parameter to null in a parameter preset clears it.

Form filling is how a page collects the values it needs. You add required parameters to the page's form, each with an entity type, an initial prompt and optional reprompt handlers.

The page keeps asking until every required parameter has a value. Once the form is complete, $page.params.status = "FINAL" becomes true, and a condition route can move the conversation forward.

Users can also fill several parameters in one sentence, such as "book a table for four tomorrow".

After the form completes, read the collected values on later pages with $session.params.name.

A webhook is an HTTPS service that Dialogflow calls when you need custom logic: looking up an order, checking a balance, calling a CRM or computing a response.

You enable it in fulfillment and pass a tag so the same service can tell which logic to run. The response can contain messages, updated parameters and, if needed, a different page to move to.

Webhooks are registered once at the agent level (URL, authentication, timeout) and then picked by name in fulfillment. CX uses its own JSON format, different from ES. Keep calls quick, and if work is slow, queue it and return a status.

Event handlers react to things that are not a normal user intent. Built-in events include sys.no-match-default (nothing matched), sys.no-input-default (silence on a voice agent) and webhook.error (a failed webhook call).

You can also define custom events and trigger them from fulfillment or webhooks. Handlers can sit on a page, a flow or a route group, and they usually send a message or transition to a recovery page.

The numbered variants sys.no-match-1, -2 and -3 fire on the first, second and third consecutive failure, so you can escalate wording step by step. A handler on a flow covers all its pages, while a handler on a page takes priority there.

The Simulator is the built-in test panel. You type or speak as a user and see the reply together with the matched intent, confidence, current page, parameter values and the raw webhook request and response.

You can start a test from a specific flow or page, which saves you from replaying earlier turns, and you can pick the environment you want to test against.

A good habit is to run the Simulator after every significant change and save the good runs as test cases. The diagnostic info also shows which parameters were set at each step, which makes an unfilled value easy to spot.

An environment is a deployment target for your agent, such as staging or production. Every agent has a Draft environment that always reflects your latest edits.

Other environments point to specific flow versions and can carry their own webhook settings, so the same agent can call a test backend in staging and the real one in production.

Teams commonly keep environments such as dev, staging and production. Each has its own deployment history and can be targeted by test cases. The session path used by your client can include the environment ID, which decides which flow versions answer users.

A flow version is an immutable snapshot of a flow taken at a moment in time. Later edits to the draft do not change it.

You deploy by pointing an environment at one or more flow versions. To roll back, you simply point the environment back at an earlier version. You can also load a version into the draft flow to continue from that state.

Versions are per flow, so you can ship a fix to the billing flow without freezing the others. Because a version cannot be edited, any change goes into the draft flow first and then into a new version.

A route group is a reusable bundle of intent and condition routes that you can attach to several pages or to a flow. You edit it once and every place that uses it picks up the change.

It is ideal for handlers that should work almost everywhere, such as "talk to an agent", "start over" or common FAQs.

A route group can hold condition routes as well as intent routes, and one group can be attached to many pages. Name groups by purpose, such as global-navigation or faq, so it is obvious where a shared behavior lives.

Test cases are saved conversations with expected results: the user inputs, matched intents, pages, parameter values and agent responses. You usually create one by recording a Simulator session.

Run them after changing intents, routes or webhooks to catch regressions before release. They can be run against Draft or any environment.

Each test case replays the recorded inputs and compares the result with what you saved. Differences show up as failed checks, such as a different page or a changed parameter value. You can tag test cases and run a chosen set, which makes a quick smoke test before release easy.

Dialogflow ES is the older edition where an agent is a flat list of intents, steered by input and output contexts. Dialogflow CX is the newer edition that replaces that with an explicit state machine of flows and pages.

ES remains supported, so many teams keep simple FAQ-style bots on ES and use CX where the dialog branches.

Each user input is sent to the agent with a session ID. Dialogflow looks up the user's active page, matches the input against the intents on routes currently in scope, runs the matched route's fulfillment and then moves to the transition target.

flowchart TD
  A["User input with session ID"] --> B["Find active flow and page"]
  B --> C{Intent matches a route in scope?}
  C -- Yes --> D["Set parameters and run route fulfillment"]
  C -- No --> E["Fire no-match event handler"]
  D --> F{Webhook called?}
  F -- Yes --> G["Merge webhook response"]
  F -- No --> H["Follow transition target"]
  G --> H
  H --> I["Run entry fulfillment of new page"]
  I --> J{Form complete and condition true?}
  J -- Yes --> H
  J -- No --> K["Return response to user"]
  E --> K

After the new page's entry fulfillment runs, the agent collects any missing form parameters and evaluates condition routes. When nothing more fires, the combined messages go back to the client.

CX drops input and output contexts. The current page itself acts as the context: only the routes available on that page, its route groups and its flow can match.

In ES you would set an output context like awaiting_date. In CX you move to a page called "Collect date" whose routes contain the date intent. Data that must survive between pages lives in session parameters, and conditions on those parameters steer the path.

When migrating, list every ES output context and ask which page it really represents. Often three or four contexts collapse into one page with a form, which removes a lot of lifespan bookkeeping.

An intent route fires when the user's utterance matches its intent. A condition route fires when a boolean expression over parameters becomes true, with no utterance needed.

A route can also hold both. Then it fires only if the intent matches and the condition is true.

When more than one condition route is true, the one listed first wins, so put the most specific route at the top. A condition-only route is also the standard way to leave a form page once $page.params.status equals FINAL.

CX uses scoped references. The prefix tells the agent where the value lives.

They work in response text, conditions and webhook parameter presets:

$session.params.age >= 18 AND $page.params.status = "FINAL"

In a message you can write Booking in $session.params.city and the value is substituted at runtime.

Use .original for exactly what the user typed and .resolved for the normalized value, such as a date turned into structured parts. A typo in a reference like $session.param.city (missing the s) usually renders as empty text, so check the Simulator when a reply looks blank.

When fulfillment has a webhook enabled, Dialogflow sends your service an HTTPS POST with a JSON body. Your service replies with JSON that can change what the user sees and where the conversation goes.

sequenceDiagram
  participant U as User
  participant D as Dialogflow CX
  participant W as Webhook
  U->>D: Utterance
  D->>D: Match intent and run route
  D->>W: POST request with tag and parameters
  W-->>D: JSON with messages and parameters
  D->>D: Merge response and transition
  D-->>U: Agent reply

Key request fields are fulfillmentInfo.tag, sessionInfo.parameters, pageInfo and intentInfo. A minimal exchange looks like this:

// request (trimmed)
{
  "fulfillmentInfo": { "tag": "order-status" },
  "sessionInfo": { "parameters": { "order_id": "1042" } }
}

// response
{
  "fulfillmentResponse": {
    "messages": [ { "text": { "text": ["Order 1042 ships tomorrow."] } } ]
  },
  "sessionInfo": { "parameters": { "order_status": "shipped" } }
}

The response may also set a targetPage or targetFlow to redirect the conversation.

If your service does not answer within the configured timeout, Dialogflow treats the call as failed and raises the built-in webhook.error.timeout event. The default timeout is short (5 seconds) and can be raised in the webhook settings, up to a documented maximum.

If no matching event handler exists, the user simply gets a generic error behavior, so define one on the page or flow. A good handler apologizes, offers a retry or routes to a fallback path.

Prevent timeouts by keeping webhooks fast: cache lookups, avoid chained slow API calls and return early where you can.

Log timeouts on your side too, so you can tell a slow dependency from a network problem.

Never leave the webhook endpoint open. CX offers several ways to authenticate calls, and you can combine them with network controls.

Always use HTTPS and validate the incoming credentials on your side.

Use a route group when the same handling is needed on many pages: "talk to an agent", "cancel", "repeat that" or a common FAQ set. Maintaining one copy beats editing twenty pages.

Keep page-level routes for step-specific behavior, like the answer to "confirm this address".

One caution: a broad route group attached to a form page can compete with the parameters you are collecting. Check in the Simulator that a user's answer is not being captured by a global intent.

If a page defines its own route for the same intent, test in the Simulator which handler wins and rename or reorder to make the intent obvious. A flow-level route is a lighter option when the behavior belongs to one flow only.

CX counts consecutive failures on a scope and offers numbered handlers: sys.no-match-1, -2, -3 and sys.no-match-default. The same pattern exists for sys.no-input-* on voice.

The counter resets when the user is understood, so each failure streak is handled on its own.

Event handlers can transition as well as reply. The third no-input on a voice agent can route to a human, while a no-match inside a form can send the user to a simpler choice-based prompt. Vary the wording each time so the agent does not sound stuck in a loop.

Each intent match has a confidence score. If the best score is below the flow's classification threshold (0.3 by default), the input is treated as a no-match.

Raising the threshold gives fewer false matches but more no-match events. Lowering it makes the agent more forgiving but increases wrong matches. Tune it per flow using real conversations, and look at the confidence shown in the Simulator diagnostic info.

Flows can have different thresholds, which helps when one flow handles short, similar utterances and another handles open requests. Look at the confidence of near-misses in the Simulator before changing the number, because the real fix is often better training phrases.

Because CX limits matching to the intents on routes in the current scope (current page, attached route groups and the flow). The model chooses among a handful of candidates instead of every intent in the agent.

That reduces ambiguity and keeps accuracy high as the agent grows. It also means a generic intent like "yes" can trigger different outcomes on different pages with no context juggling.

It also changes how you handle conflicts. Two intents with similar phrases only collide when both are reachable from the same page, so you can often resolve a clash by moving one intent to a different page instead of rewriting phrases. Route groups and flow-level routes widen the scope, so attach things globally only on purpose.

Treat flows like modules. A common layout is a thin router on the Start page and one flow per business domain.

1. Create one flow per domain (billing, orders, account) so each has its own pages and NLU settings.
2. Route from the Start page to each flow with intent routes.
3. Put shared handlers such as "agent" and "start over" into route groups.
4. Return with the End Flow target so control goes back to the page that handed off.
5. Agree on parameter names across flows, since session parameters are shared.
6. Version and test each flow separately.

Document the flow map in the agent description so new teammates can find the entry points quickly.

Work in the Draft environment, then freeze what you tested as flow versions and deploy those.

flowchart LR
  A["Edit draft flows"] --> B["Run test cases on Draft"]
  B --> C["Create flow versions"]
  C --> D["Point staging environment at versions"]
  D --> E["Run test cases on staging"]
  E --> F["Point production environment at versions"]
  F --> G["Monitor conversations"]
  G -->|Issue found| H["Re-point to earlier version"]

Each environment can override the webhook URL, so staging talks to a test backend while production calls the live one. Rolling back is just pointing the environment at an earlier version.

Record which flow versions went to production at each release so audits and rollbacks are quick.

Voice agents accept both spoken words and keypad digits. DTMF settings on a page or form parameter let you enable digit capture, set the maximum digits and choose a finish digit such as #.

For speech, use speech adaptation to bias recognition toward your domain terms (product names, account words) and tune barge-in and timeout behavior. Silence is handled by sys.no-input-* event handlers.

Voice responses can use SSML for pauses and pronunciation, and you choose the text-to-speech voice in agent settings. Keep phone prompts short, because callers cannot scan options the way readers can, and give a DTMF fallback for noisy lines.

Generative fallback lets an LLM write the reply when the user's input matches no intent. You enable it in the fulfillment of a no-match event handler and supply a prompt that guides the answer.

For example, the prompt can tell the model to apologize, stay on topic and suggest what the agent can help with. The rest of the flow stays deterministic, and generative requests are billed as generative usage.

Use the prompt to restrict scope. Tell the model which topics the agent covers, ask it to avoid promises or prices and keep answers short. You can also add banned phrases and review outputs in the Simulator, because a rambling fallback hurts trust more than a plain apology.

A generator is a reusable LLM prompt you call from fulfillment to produce text on demand. You write the prompt, choose model settings and insert placeholders such as $conversation or $last-user-utterance.

Typical uses are summarizing the chat for a human agent, rewriting a webhook result in a friendlier tone or extracting a value. The output can be sent to the user or saved in a parameter.

Because the prompt lives outside the flow, one generator can be reused on several pages and tuned in one place. Keep prompts narrow, state an output format such as a two-sentence summary, and test with real transcripts, since long inputs can drift from the instructions.

Playbooks let you define agent behavior in natural language. You write a goal, step-by-step instructions and optional examples, and attach tools the agent may call.

The LLM decides at each turn what to say and which tool to use, so there is no need to draw every page and route. You trade some determinism for faster building and more natural dialogs.

Good instructions are specific: the goal, the order of steps, what to do when a tool fails and what the agent must never do. Playbooks can also hand control to other playbooks or flows, so one playbook does not have to cover everything. Review behavior with real conversations, not only the happy path.

Tools are how a playbook reaches beyond the model. The main types are:

Each tool has a description, and the playbook instructions refer to it by name so the model knows when to use it.

Tool descriptions matter as much as the tool itself, because the model decides when to call it largely from that description and the input schema. Name inputs clearly and say what the tool returns, including error cases.

A data store ingests your content, such as website pages, unstructured documents like PDFs and HTML, or structured data. At runtime the agent retrieves the most relevant passages and the LLM composes an answer from them, often with source links.

You can use a data store from a flow (data store handler) or from a playbook (data store tool). Because answers come from your content, hallucinations drop and updates only need re-indexing, not retraining.

To keep answers safe, tune the grounding and summarization settings, add banned phrases and test with questions the content cannot answer. A good agent says it does not know rather than guessing. Refresh the index when the source pages change.

Choose flows when every word and step must be controlled: payments, identity checks, regulated disclosures. Choose playbooks for open-ended help where users ask many things in many orders.

Many production agents are hybrid: a playbook handles the open conversation and a flow handles the sensitive step.

Latency and cost differ too. A flow turn is cheap and fast, while a playbook turn involves one or more LLM calls, and tool calls add more. For high-volume voice traffic with simple tasks, that difference can decide the design.

Examples are sample conversations that show the model how to follow your instructions, including when to call a tool and how to phrase the reply. They work like few-shot prompts.

Good example sets cover the happy path and edge cases, such as a tool returning an error or the user changing their mind. Keep them consistent with the instructions, because contradictions confuse the model.

Examples are also a debugging tool. If the agent keeps skipping a step, add an example that shows the step happening in the right place. If it calls a tool too early, add one where the model asks a clarifying question first.

Use each tool where it is strongest. A typical pattern is a playbook for the open conversation and a flow for a rule-bound step like collecting a card number or verifying identity.

Playbook instructions can refer to a flow by name (for example ${FLOW: verify_identity}) so the model hands over at the right moment. A flow route can also transition to a playbook, and the agent's start resource can be either one.

Test the handoff points carefully, and confirm the exact syntax in the current docs, because the generative features evolve quickly.

Pass what the flow needs as parameters when you hand over, and read the results back after the flow ends.

Work from the cheapest check to the deepest.

1. Confirm a route with that intent is in scope on the page the user is actually on.
2. Open the Simulator diagnostic info and look at the matched intent and confidence versus the threshold.
3. Check whether the route also has a condition that is currently false.
4. Look for competing intents with similar training phrases.
5. Review phrase variety and parameter annotations.
6. Add a test case once fixed so it stays fixed.

Also check the language. An intent with phrases only in English will not match a conversation running in another language, and a mismatched language code is an easy cause of constant no-match to overlook.

Aim for quality and variety rather than volume. Use real user utterances from conversation history where you can, and add different sentence shapes, lengths and vocabulary.

• Annotate parameters so entities generalize.
• Avoid single-keyword phrases that clash with other intents.
• Remove or reword overlapping phrases across similar intents.
• Keep intents reasonably balanced in size.
• Hold back a few phrases and use them to test.

Re-test after each change. Paste several unseen variants into the Simulator and watch the confidence: low scores on natural phrasings mean the intent lacks coverage, and two intents scoring close together need clearer separation. Keep a few phrases out of training as a held-back test set.

Start in the Simulator: its diagnostic panel shows the exact request sent and the response (or error) received. Then narrow down.

1. Identify the event: webhook.error (bad status or response) versus webhook.error.timeout (too slow).
2. Verify URL, HTTPS certificate and authentication settings for the right environment.
3. Check your service logs in Cloud Logging for the incoming request and tag.
4. Validate the response JSON: the messages must sit under fulfillmentResponse.messages.
5. Confirm the tag in fulfillment matches what the code expects.

A 200 response with a malformed body often looks like "agent says nothing".

If the failure happens in only one environment, compare that environment's webhook override with the agent-level setting.

Record important conversations as test cases, then run them automatically whenever the agent changes. The Dialogflow API supports running test cases in batches, so a CI job can run them against a staging environment before you promote.

Review the coverage report, which shows how many intents, transitions and route groups your test cases exercise. Gaps tell you where to add new cases.

Fail the pipeline on any difference between expected and actual results, and only then create production flow versions.

Keep test cases small and focused, one scenario each, so a failure points at one cause. Name them clearly, and update expected results on purpose when behavior changes deliberately instead of ignoring red tests.

Create a sessions client, build a session path that includes your project, location, agent ID and a session ID, and send a DetectIntentRequest.

from google.cloud import dialogflowcx_v3 as cx

client = cx.SessionsClient(
    client_options={"api_endpoint": "us-central1-dialogflow.googleapis.com"})
session = client.session_path("my-project", "us-central1", "AGENT_ID", "session-123")

request = cx.DetectIntentRequest(
    session=session,
    query_input=cx.QueryInput(text=cx.TextInput(text="track my order"),
                              language_code="en"))
response = client.detect_intent(request=request)
for msg in response.query_result.response_messages:
    print(msg.text.text)

Reuse the same session ID for every turn of one user's conversation. Agents in a region other than global need the matching regional endpoint.

For streaming audio, use the streaming detect-intent call instead. For text, the standard call above is enough. You can also pass query parameters, such as a customer ID, in the request to prefill session values.

CX agents can be published through built-in integrations or your own client code.

To tailor content per channel, send custom payloads in fulfillment that your channel or client understands, and keep the shared logic in the same flows.

Test each channel separately, since text length, buttons and audio behave differently. A rich card may render on one channel and not on another, so include a plain text message as a fallback.

Add a live agent handoff response in the fulfillment of the route or page where escalation should happen. You can include metadata (reason, customer ID, summary) that your integration reads.

When it fires, the agent returns the handoff message in the response and your contact-center platform or custom code routes the user to a human. Pass context through metadata and session parameters so the person does not have to repeat themselves.

Common triggers are the user asking for a person, a high-value request, or a third consecutive no-match.

Dialogflow only signals the handoff, so the actual transfer is done by your integration.