Cloud / Google Cloud Dialogflow ES (Essentials) Interview questions

Dialogflow ES (Essentials) is Google Cloud's natural language understanding (NLU) service for building text and voice chatbots. It takes a user utterance, maps it to an intent, pulls out parameters, and returns a response, either a static reply or one built by your own webhook.

ES is the original, intent-based edition. Conversation state is tracked with contexts rather than a visual flow. Dialogflow CX is the newer flow-and-page edition aimed at larger, more complex agents.

Typical uses are customer-support bots, voice IVR front ends, FAQ assistants and smart-device commands. You can reach an agent through the console, the REST/gRPC API, client libraries or ready-made integrations such as Slack and Telephony.

An agent is the top-level container for one conversational application. It holds your intents, entities, contexts, fulfillment settings, ML settings and integrations, and it is the thing you call through the API.

Each agent lives inside a Google Cloud project, has a default language, and can be exported as a ZIP file. One project can hold only one ES agent, so teams that need several bots usually use several projects.

Think of it as a compiled NLU module: you describe intents and examples, Dialogflow trains a model, and the agent answers queries against that model.

An intent represents one thing the user wants, for example book a table or check order status. Dialogflow matches each incoming query to the best-fitting intent and then runs whatever that intent defines.

An intent is made up of these parts:

• Training phrases - example utterances for the ML model
• Action and parameters - values extracted from the query
• Contexts - input and output contexts for multi-turn state
• Events - non-text triggers
• Responses and fulfillment - static replies or a webhook call

The matched intent's name, parameters and confidence come back in the queryResult of the detect-intent response.

Training phrases are example sentences a user might say to trigger an intent. Dialogflow uses them to train its ML model, so it can match phrasings you never wrote down, not just exact copies.

Good phrases vary wording, length and word order. Google suggests supplying at least 10-20 for each intent, and more when the intent has several parameters. Words that belong to an entity are annotated, so tomorrow in book a table for tomorrow is tagged with @sys.date and becomes a parameter.

Dialogflow retrains automatically when you save an intent, so no manual training step is needed in the console.

Entities describe the kind of data you want to pull out of an utterance, such as a city, a date or a product size. An entity type is the category (for example @size), and each entity entry is one value inside it.

When a training phrase contains an annotated entity, the value found at runtime is stored in an intent parameter. Your webhook or response can then use it with $parameter syntax.

Dialogflow already ships system entities like @sys.date and @sys.number, and you create developer entities for domain data such as plans or branches.

Dialogflow ES has three kinds of entity types: system, developer and session.

Developer entities come in three forms: map (reference value plus synonyms), list (values with no reference value) and composite. A regexp entity is also available for pattern-based values like order IDs.

A context is a named piece of conversation state that Dialogflow attaches to a session. It lets the agent remember what was just discussed, so short replies like yes or the second one are understood.

Intents use contexts two ways. An input context limits an intent so it can only match while that context is active. An output context is activated when the intent matches, and it can carry parameter values forward.

Every context has a lifespan, counted in requests and in time, after which it expires. Names are lowercase, and full names follow projects/<id>/agent/sessions/<session>/contexts/<name>.

Fulfillment lets your agent do real work instead of returning only canned text. When an intent has webhook calls enabled, Dialogflow sends the matched intent and parameters to your service and uses the response it gets back.

Typical jobs are looking up an order, writing a booking to a database, calling a payment API or building a response that depends on the user's data.

There are two ways to host the logic: your own HTTPS webhook, or the console's inline editor, which deploys a Node.js Cloud Function for you. Enable fulfillment per intent with the Enable webhook call for this intent switch.

The Default Fallback Intent is the catch-all that fires when no other intent matches the user's input above the classification threshold. It is created automatically with every new agent and uses the built-in FALLBACK event.

Its responses are usually phrases like Sorry, I didn't get that. You should rewrite them to guide the user, for example by listing what the bot can do, and you can add several variations so replies do not feel repetitive.

Reviewing the fallback hits in the Training and History views is a quick way to find missing intents or missing training phrases.

The Default Welcome Intent greets the user at the start of a conversation. It includes greeting training phrases such as hi and hello and is tied to the WELCOME event.

Many integrations send the WELCOME event automatically when a chat opens, so the bot can speak first without waiting for text. Use the intent to introduce the bot and suggest next steps, ideally with quick replies.

Edit the default replies to match your brand, since they are generic by design.

Parameters are the named values Dialogflow extracts from a user query. Each one has a name, an entity type, a value, and optionally a default value, a prompt list and an is list flag.

If a user says Book a table for 4 tomorrow, the intent could return number = 4 and date = 2026-10-30. You can reuse them in responses with $name, read them from a context with #context.name, or read them in your webhook from queryResult.parameters.

Marking a parameter required turns on slot filling, so Dialogflow keeps asking until it has a value.

A follow-up intent is a child intent that only matches right after its parent. Dialogflow wires them together automatically: the parent gets an output context named like parentname-followup, and the child gets the same name as an input context.

Predefined follow-ups cover common short answers, including yes, no, later, cancel, more, next, previous, repeat and select.number, plus a custom type you define yourself.

They are quick for simple confirmations. For longer, branching conversations, manually managed contexts give more control.

Both editions run the same ES agent. The difference is billing, quotas and support.

To raise quotas on an ES agent you must first upgrade it to Essentials, as Google's quota documentation states. Agents are upgraded in the agent settings, and billing must be enabled on the project.

An event is a non-text trigger that can match an intent. Instead of a user phrase, you pass an event name (and optional parameters) in the detect-intent request or from a webhook, and Dialogflow runs the intent that lists that event.

Built-in examples are WELCOME and FALLBACK. Custom events let you start a conversation from outside, such as a button click, or have a webhook jump to another intent through followupEventInput.

An intent can list both training phrases and events, so it can be reached either way.

Intents can return plain text and richer message types. The common ones are:

• Text response - one or more variations, one chosen at random
• Image
• Card - title, subtitle, image and buttons
• Quick replies - tappable suggestion chips
• Custom payload - free-form JSON your client or integration interprets

Responses can be set for a specific platform, such as Slack or Dialogflow Messenger, with a Default tab for everything else. If no platform-specific message exists, Dialogflow falls back to the default one.

Rich message support differs by integration, so always test on the real channel.

Dialogflow ES offers built-in connectors so you do not write channel code yourself. Common ones include:

• Dialogflow Messenger - an embeddable web chat widget
• Telephony - phone gateway for voice calls
• Slack, Telegram, Twilio, Facebook Messenger and other messaging platforms
• Web demo - a quick shareable test page

Anything not covered can use the detect-intent API directly from your own backend or app. Note that conversational Actions for Google Assistant were discontinued in 2023, so new designs should not depend on them.

Rich responses differ per integration, which is why platform-specific message tabs exist.

Open the Dialogflow ES console, choose or create a Google Cloud project, and create the agent. Then build it up in this order:

1. Pick a name, default language and time zone, then click Create.
2. Add intents with at least 10-20 training phrases each.
3. Annotate entities and mark required parameters if you need slot filling.
4. Add responses, or enable fulfillment for dynamic ones.
5. Test in Try it now, then connect an integration or call the API.

Keep in mind that the default language cannot be casually changed later, so choose it before adding content. A new agent already contains the Default Welcome and Default Fallback intents.

The inline editor lets you write fulfillment code directly in the console, with no separate server. When you click Deploy, Dialogflow publishes it as a Cloud Function and wires the webhook URL for you.

It has an index.js using Node.js and a package.json for dependencies. Handlers are mapped to intent names, which is convenient for prototypes and small bots.

const intentMap = new Map();
intentMap.set('Order Status', orderStatusHandler);
agent.handleRequest(intentMap);

For production you will often outgrow it, since you cannot easily use CI/CD, tests or other runtimes. In that case host your own webhook.

A session is one conversation between an end user and your agent. You identify it with a session ID that your client generates and sends with every detect-intent request. It can be up to 36 bytes long.

Contexts, session entities and parameters belong to a session. Reusing the same ID continues the conversation, while a new ID begins a fresh one with no memory.

Use a unique ID per user conversation, and avoid using personal data such as an email address as the ID.

Knowledge connectors let an agent answer from documents instead of hand-built intents. You attach a knowledge base of FAQ pairs or articles, from sources like CSV, HTML or URLs, and Dialogflow finds the best passage for a query.

They are useful for large FAQ content that would take hundreds of intents to model. Enable them under the intent or default fallback area and set a confidence threshold so weak matches are ignored.

Answers from a knowledge base are generally less controlled than intent responses, so keep high-value flows such as payments as normal intents.

All three live under Settings > Export and Import, and each handles the agent as a ZIP file.

Use export for backups and for promoting changes between projects, for example from a dev project to a prod project. The ZIP is also easy to keep in Git for review.

A regexp entity matches values by a regular expression rather than a list of words. It suits formats such as order IDs, ticket numbers or postal codes, where listing every value is impractical.

For example, an @order_id entity could use ORD-[0-9]{6}. Any text in the query matching that pattern is extracted as the entity value. Because an entity defines only the pattern, it does not understand context, so add training phrases that show how the value appears in a sentence.

Use anchors and tight patterns, because loose expressions match unintended text.

Dialogflow first narrows the candidates, then scores them. Intents whose input contexts are not active are filtered out. The remaining intents are scored against the query using the ML model and, in hybrid mode, rule-based matching on training phrases.

The best-scoring intent wins only if its confidence reaches the agent's classification threshold. Otherwise the Default Fallback Intent is used. Event inputs skip this scoring and go straight to the intent that lists the event.

flowchart TD
  A["User query and session"] --> B["Filter intents by active input contexts"]
  B --> C["Score with ML and rule-based matching"]
  C --> D{Confidence above threshold?}
  D -- Yes --> E["Matched intent and parameters"]
  D -- No --> F["Default Fallback Intent"]
  E --> G{Webhook enabled?}
  G -- Yes --> H["Call webhook"]
  G -- No --> I["Static response"]

Once an intent matches, parameters are extracted from the annotated entities and the response, or webhook, is run.

The ML classification threshold is the minimum confidence score, between 0 and 1, an intent must reach to count as a match. The default is 0.3, and you change it in Settings > ML Settings.

Raising it makes the agent stricter: fewer wrong matches, but more fallbacks on valid phrasing. Lowering it makes the agent more forgiving but increases the risk of the bot answering the wrong intent.

The score of the matched intent is returned as intentDetectionConfidence, so you can log it and tune the threshold using real traffic instead of guessing.

Hybrid mode combines rule-based grammar matching with the ML model. If a query closely matches a training phrase, the rule-based path can match it even when the ML score is low. It works well for new or small agents with few examples.

ML Only relies entirely on the ML model, which generalizes better across phrasings once an agent has many training phrases and intents.

You switch modes in Settings > ML Settings. Retest your key utterances after switching.

An intent's output context switches on a context after the intent matches. Another intent's input context requires that context to be active before it can match. Chained together they build a multi-turn conversation.

Example flow: order.pizza sets the output context awaiting-size. Only the intent order.pizza.size, which lists awaiting-size as input, can match the next reply of large. Without that guard, a bare large would hit the fallback.

If an intent lists several input contexts, all of them must be active. Parameters from an output context can be read later with #awaiting-size.pizza.

A new output context in the console starts with a lifespan of 5 requests. It expires after 5 further queries, and it also expires after 20 minutes without a matching query, whichever comes first.

Change it in the intent's output context by editing the number next to the context name. A lifespan of 0 removes the context straight away. From a webhook, set lifespanCount on the context in the response.

"outputContexts": [{
  "name": "projects/p1/agent/sessions/s1/contexts/awaiting-size",
  "lifespanCount": 2,
  "parameters": {"pizza": "margherita"}
}]

Keep lifespans short. Long-lived contexts can leave the user stuck in a branch after they change topic.

Slot filling is how an intent collects every value it needs before responding. Mark a parameter as Required, add one or more prompts, and Dialogflow keeps asking until the slot has a value.

1. The user says Book a table, and the intent matches.
2. A required date is missing, so Dialogflow replies with the prompt What day?
3. The user answers tomorrow, and the entity fills the slot.
4. Once all required slots are filled, the response or webhook runs.

If the user supplies several values in one sentence, those slots are filled together. In the webhook request, allRequiredParamsPresent tells you whether collection is finished. You can also enable webhook call for slot filling to validate values on every turn.

Dialogflow sends an HTTPS POST with a JSON WebhookRequest. The useful parts are queryResult.queryText, queryResult.intent.displayName, queryResult.parameters and the outputContexts. Your service replies with a WebhookResponse such as fulfillmentText, fulfillmentMessages, outputContexts, payload or followupEventInput.

sequenceDiagram
  participant U as User
  participant D as Dialogflow
  participant W as Webhook
  U->>D: Utterance
  D->>D: Match intent and extract parameters
  D->>W: POST WebhookRequest
  W-->>D: WebhookResponse JSON
  D-->>U: Reply

app.post('/webhook', (req, res) => {
  const qr = req.body.queryResult;
  const city = qr.parameters['geo-city'];
  res.json({ fulfillmentText: `Weather lookup for ${city}` });
});

The endpoint must be HTTPS and respond within about 5 seconds.

If the webhook times out, returns a non-success HTTP status, or sends invalid JSON, Dialogflow does not crash the conversation. It uses the static response defined on the intent when there is one. If none exists, the user gets no useful reply.

The error details appear in the webhookStatus field of the detect-intent response and in Diagnostic info in the console. The deadline is about 5 seconds, so slow lookups are the most common cause.

So always give every webhook-enabled intent a friendly static fallback such as I'm having trouble checking that right now. It acts as a safety net during outages.

Create a SessionsClient, build a session path from your project ID and a session ID, wrap the text and language in a QueryInput, and call detect_intent. The caller needs a service account with the Dialogflow API Client role.

from google.cloud import dialogflow

client = dialogflow.SessionsClient()
session = client.session_path(project_id, session_id)
text = dialogflow.TextInput(text="Where is my order?", language_code="en-US")
query = dialogflow.QueryInput(text=text)
resp = client.detect_intent(request={"session": session, "query_input": query})
print(resp.query_result.fulfillment_text)

Reuse the same session ID for each turn of one conversation. To target a specific environment, include it in the session path.

ES models a bot as a set of intents linked by contexts. CX models it as a visual state machine of flows and pages. Both understand natural language, but CX scales better when conversations get complicated.

They are separate products with separate APIs, and an ES agent is not upgraded in place to CX.

Choose CX when the conversation is long, branches a lot, or is built by several people. Those are the situations where ES agents turn into a tangle of contexts and follow-up intents.

• Many pages of data collection, like claims or onboarding
• Multiple teams editing different flows
• A need to visualize and review the conversation path
• Large agents with many intents

Choose ES for a straightforward FAQ or a handful of transactional intents, where a form-based console is quick and enough. ES is also the practical choice when an existing agent works and the team has no reason to rebuild it.

Moving later takes planning, so decide early based on expected complexity.

Session entities are entity types created through the API for one session only. They let you customize entity values per user at runtime, such as a user's contacts, saved addresses or playlists.

You create one with the same name as an existing developer entity and choose an entityOverrideMode. OVERRIDE replaces the developer entries for that session, and SUPPLEMENT adds to them.

POST .../sessions/SESSION_ID/entityTypes
{
  "name": ".../entityTypes/contact",
  "entityOverrideMode": "ENTITY_OVERRIDE_MODE_SUPPLEMENT",
  "entities": [{"value": "Priya", "synonyms": ["Priya", "my sister"]}]
}

They disappear when the session ends, so nothing leaks to other users.

There are three directions to remember.

• Client to webhook: set queryParams.payload in the detect-intent request. It arrives in the webhook at originalDetectIntentRequest.payload.
• Integration to webhook: channels such as Slack put their own user and channel details in the same originalDetectIntentRequest field.
• Webhook to client: return a payload object, or a custom payload message, which your app reads from the response.

Use this for values such as a user ID, app version or auth token that should not be spoken by the user. Do not place secrets in a place that is logged without masking.

Contexts are the right tool when the data must persist across turns, because payload applies only to a single request.

When two intents contain near-identical phrases, the ML model cannot separate them. Queries then flip between the two intents or land on the wrong one with a low confidence score.

This usually happens with short generic phrases such as cancel or help placed in several intents, or with an intent that was split too finely.

1. Open the Validation tab to see which phrases overlap.
2. Remove or reword the duplicates so each intent has distinct examples.
3. Merge intents that differ only by a value and use an entity parameter instead.
4. Use input contexts so only one of the similar intents is eligible at a time.

After a fix, retest with the actual phrases that failed.

Each intent has a priority level shown by a colored dot: Highest, High, Normal (default), Low and Ignore. When several intents could match, Dialogflow can prefer the higher-priority one.

The Ignore level removes the intent from matching entirely. It is handy for retiring an intent without deleting it.

Treat priority as a tie-breaker. Using it to hide poor training data tends to cause new problems elsewhere, so fix the phrases or contexts first. Typical good uses are making a short high-value intent like cancel order win over a broader one, or lowering a very general intent.

The draft agent is what you edit. Publishing takes a snapshot of it, called a version, that never changes. An environment points to a version, so you can run a stable one while continuing to edit the draft.

Each environment can have its own fulfillment and integration settings. Clients target one by including it in the session path, such as projects/p/agent/environments/prod/sessions/s. Roll back by pointing the environment to an older version.

Start with the basics: the webhook must be served over HTTPS, and it should reject any request that cannot prove it came from your agent.

• Add basic auth or custom headers in Fulfillment settings, and check them on every request.
• For Cloud Functions or Cloud Run services that require authentication, grant the Dialogflow service agent permission to invoke them.
• Validate and sanitize parameter values before using them in queries.
• Avoid logging personal data, or mask it first.
• Give the service account only the roles it needs.

Dialogflow's authentication options change, so confirm the current ones in the Fulfillment documentation before relying on a specific setup.

Work from the evidence in the console before changing anything.

1. Run the phrase in Try it now and open Diagnostic info to see the matched intent and confidence.
2. Check active contexts. An intent with an input context cannot match unless that context is live.
3. Compare against the ML threshold. A score just under it means more or better training phrases are needed.
4. Open Validation to find overlapping phrases in other intents.
5. Confirm the language and match mode, and that training has finished.
6. Check History and Training for similar real queries.

Fix one cause at a time and retest the same phrase so you know which change helped.

First check Diagnostic info. It shows the request Dialogflow sent, the response it got, and any webhookStatus error.

• Timeout: the service took longer than about 5 seconds.
• Auth or HTTPS error: bad certificate, wrong credentials or blocked URL.
• Bad response: invalid JSON, wrong field names or a non-200 status.
• Logic bug: wrong handler for the intent name.

Enable Log interactions to Google Cloud in settings and read the Cloud Logging entries for both Dialogflow and your function. To debug locally, copy the request JSON from Diagnostic info and replay it with curl, or expose a local server through a tunnel for live testing.

The webhook sits in the middle of every reply, so every slow call is heard by the user. The main levers are:

• Keep a minimum number of instances warm in Cloud Functions or Cloud Run to avoid cold starts.
• Host the service in the same region as the agent.
• Cache lookups that rarely change.
• Run independent API calls in parallel instead of in sequence.
• Enable the webhook only on the intents that need it.
• Reply quickly and finish slow work asynchronously.

Remember the roughly 5 second deadline. A webhook that regularly takes 3 to 4 seconds will fail under load, so measure the slowest path and not the average.

Add each language to the same agent from the Languages tab. Intent names, parameters and contexts are shared, and each language gets its own training phrases, responses and entity synonyms.

In the detect-intent request, send the matching languageCode, for example es or de. Your webhook sees the same intent names and can read queryResult.languageCode if replies must differ by language.

Dialogflow does not translate content for you. Write real examples in every language, because direct translations of English phrases often miss how people actually talk. Check that each language has a response for every intent, or users get blanks.

Dialogflow can take audio directly. In detectIntent you pass input_audio with an InputAudioConfig giving the encoding, sample rate and language. For live conversations, StreamingDetectIntent streams audio and returns interim text as the user speaks.

Dialogflow transcribes the audio and then matches the transcript like any other query. To make recognition better for your domain, use speech adaptation (phrase hints, or the agent's automatic adaptation from training phrases).

For spoken replies, add an OutputAudioConfig so the answer comes back as synthesized audio. The Telephony integration wraps all of this for phone calls.

Quotas depend on the edition and on the request type. Text, audio and other session calls such as getting or setting contexts are counted separately. Check current values on the Dialogflow Quotas page in the Cloud console.

1. Upgrade the agent to the Essentials edition, which is required before you can request an increase.
2. Request more quota for the right metric if you expect real traffic.
3. Spread load across several projects where it makes sense.
4. Retry 429 RESOURCE_EXHAUSTED errors with exponential backoff.
5. Cut unnecessary calls, for example by not calling detectIntent for every keystroke.

Load-test before a launch, because quota increases are not instant.

These are three separate options on a developer entity type and each solves a different problem.

Turn on Define synonyms for map entities. Use automated expansion for open-ended categories but not for strict ones like plan codes, where an unknown value must be rejected. Fuzzy matching helps with typed chat but can match too loosely for short values.

Follow-up intents are a shortcut: they are bound to one parent and sit in a fixed tree. Custom contexts give you control over that structure.

• One child intent can be reached from several parents, by listing the same input context.
• You decide the lifespan of each step.
• Parameters can be carried forward through the context.
• Users can wander off-topic and come back, since state is not tied to a single branch.

Follow-up intents are still fine for a simple yes/no confirmation after one question. As flows grow, the number of auto-generated child intents becomes hard to maintain, and custom contexts keep the agent smaller.

Use several layers of checking together.

• Validation tab: shows errors and warnings such as overlapping phrases or missing responses.
• Try it now: manual checks with Diagnostic info for confidence and contexts.
• Regression script: loop over a list of utterances and expected intents through the detect-intent API, then fail if any result changes.
• Environment test: run the same suite against staging before promoting the version.
• Unseen phrasing: test wording that is not in the training set.

Keep the test list in version control and add a case for every bug fixed. Track confidence as well as intent name, because a match that drops close to the threshold is an early warning.

Return the same context in outputContexts with lifespanCount set to 0. Dialogflow removes it as soon as the response is processed.

{
  "fulfillmentText": "Order cancelled.",
  "outputContexts": [{
    "name": "projects/p1/agent/sessions/s1/contexts/awaiting-size",
    "lifespanCount": 0
  }]
}

From the API you can use the context delete method for one context, or delete all contexts of a session. A client can also send resetContexts: true in queryParams of a detect-intent request to start the turn clean.

Resetting is useful after a flow finishes or is cancelled, so old state does not affect the next conversation.

Turn it on in the agent settings, or per request with queryParams.sentimentAnalysisRequestConfig.analyzeQueryTextSentiment = true. The response then includes sentimentAnalysisResult.queryTextSentiment.

It has two numbers. Score runs from -1.0 (negative) to +1.0 (positive). Magnitude is zero or higher and shows how strong the emotion is overall, regardless of direction.

A practical use is escalation: if the score stays strongly negative over a couple of turns, hand the chat to a human agent or switch to an apology intent. Do not treat a single score as proof of mood, since short messages are noisy.