AWSAWS Certified Generative AI Developer - Professional2026-102.5 Implement application integration patterns and development tools

Extend conversations through bounded business adapters

Completed by the knowledge check

Learning objective

Extend CRM, contact-center, and conversational applications using Lambda, Amazon Lex, Amazon Connect, and Amazon Q Business

Core idea

Extend an existing conversation by identifying the boundary that lacks a capability. A customer relationship management (CRM) operation needs an authorized business adapter. A bot needs conversation-state transitions. A contact center needs call-flow behavior and a bounded wait. An enterprise assistant needs approved operations exposed through its integration contract.

AWS Lambda can implement adapter logic, Amazon Lex V2 can manage intent and slot interactions, and Amazon Connect can invoke an adapter from a contact flow. Amazon Q Business custom plugins expose third-party API operations to an enterprise assistant. These services have different event formats and completion semantics; a generic “chatbot integration” does not erase those differences.

Q Business also has an availability boundary: it is closed to new customers, with bug fixes and security updates continuing for existing customers and no new feature requests considered. AWS recommends Amazon Quick for new solutions. This Bite covers extending an existing Q Business environment; the broader product choice is covered in 2.5.3.

How it works

Keep the CRM operation in a business adapter

Use a Lambda handler as an adapter when the conversation must call a business operation with validated parameters and a controlled response. The adapter should translate the caller’s event into a specific CRM request, check the authenticated user’s permission, and return a bounded result. It should not forward arbitrary generated text as an instruction to update a record.

Separate read operations from writes. Looking up an existing case and creating another case have different duplicate and authorization consequences. Define an application operation identity for a write and reconcile retries against the authoritative CRM result. The general legacy adapter and authorization patterns are covered in 2.3.1 and 2.3.7; here the important addition is matching the adapter to the conversation surface’s event contract.

A generated explanation can help a customer understand a case, but it should not determine whether the case exists. Return structured adapter status independently of any generated message.

Use Lex code hooks for dialog and fulfillment

Lex V2 integrates one Lambda function per bot alias per language, rather than one function per intent. Route inside that handler using the invocation context and intent.

The input event’s invocationSource distinguishes DialogCodeHook from FulfillmentCodeHook. A dialog hook runs after user input. A fulfillment hook runs after required slots are filled and the intent is ready for fulfillment. A slot being populated is conversation evidence; the adapter must still validate its value and authorization before a CRM write.

Return Lex’s response structure. sessionState is required and includes dialogAction.type. Delegate lets Lex determine the next step. ElicitSlot requests a named slotToElicit and requires the intent name. ConfirmIntent requires the intent name, the slots to confirm, and a message asking for confirmation. Close terminates the intent with an appropriate intent state.

Keep model-generated wording in the message content where appropriate. Do not replace sessionState with free-form text. If a generated reply says a refund is approved while the adapter reports rejection, the business status governs the state transition and the reply must be corrected or withheld.

For questions outside the other intents, AMAZON.QnAIntent uses a Bedrock foundation model and a configured knowledge store, such as a Bedrock knowledge base. Enable generative AI capabilities for the bot locale. This intent cannot coexist with AMAZON.KendraSearchIntent in that locale and does not activate for missed utterances during slot elicitation.

Bound Connect’s Lambda wait

Connect’s Get customer input block runs a Lex V2 bot inside the contact flow. For chat, the block works only when Lex is used; otherwise it takes the Error branch.

The Connect Lambda flow block supports synchronous and asynchronous execution modes. In synchronous mode, the contact moves to the next block after invocation completion, with a maximum configured timeout of 8 seconds. In asynchronous mode, it moves on without waiting, with a maximum configured timeout of 60 seconds.

These are Connect block boundaries, not the function’s general execution allowance. Select a synchronous lookup only when it can return within the contact’s wait budget. Do not put an unbounded generation or slow CRM operation behind an 8-second synchronous promise.

For asynchronous execution, Connect provides a Wait block and a Load Lambda Result action. $.LambdaInvocation.InvocationId holds the request ID of the most recent asynchronously invoked Lambda, and Load Lambda Result uses the invocation request ID. Preserve the correct identity when several operations exist so the contact does not consume another operation’s result.

The block’s Response validation setting selects STRING_MAP or JSON. Match the handler’s return structure to that setting. Connect retries throttled invocations and general service failures. When a Lambda invocation returns an error, it retries up to three times within the configured timeout before taking the Error branch. Because the caller can retry, a handler that creates a CRM record needs duplicate protection even when the flow appears to contain only one invocation block.

The execution mode decides whether the contact waits for the invocation.

Route the configured error and timeout paths to a deliberate customer outcome: clarification, a later status update, or an agent handoff. Avoid treating an asynchronous block’s progress as proof that its business operation completed.

Expose existing Q Business actions through plugins

An existing Q Business application can use a custom plugin to query or act on a third-party application. Its OpenAPI schema lets Q Business determine which API operations to call. The schema defines at least one and at most 20 operations, with one configured endpoint per custom plugin.

The schema requires OpenAPI 3.0.0 or higher. The servers entry supplies connectivity, while operation description and responses explain what an operation does and how to interpret its result. Plugin response content supports application/json.

Document required parameters clearly and expose narrow operations. Authentication and business authorization still belong at the API boundary. A schema’s description helps action selection; it does not grant the user permission to perform that action.

Key distinctions and trade-offs

Dialog versus fulfillment: Lex’s invocationSource tells the handler why it ran. Conversation validation and business completion are separate stages, even if one Lambda handles both.

Contact progress versus operation completion: Connect asynchronous mode allows the contact to move on before Lambda finishes. Load the identified result before treating the business task as complete.

Plugin contract versus arbitrary API exposure: Q Business uses a constrained OpenAPI integration. Fit the operation count, endpoint, and response contract, and enforce permission in the adapter.

Existing integration versus new service adoption: Q Business remains relevant to existing customers, but its closure changes the answer for a new customer. Similar Quick capabilities do not guarantee an unchanged API migration.

Architecture / decision scenario

A support organization wants customers to check a case, clarify a case identifier, and request a follow-up. It also has an existing Q Business assistant for employees who review and update cases.

Connect runs the Lex bot through Get customer input. Lex uses a dialog hook to validate the case identifier and returns ElicitSlot when it is missing. Questions outside the business intents can use AMAZON.QnAIntent; missed utterances during slot elicitation cannot. A fulfillment hook calls the authorized CRM adapter. Connect uses synchronous Lambda only for the bounded lookup; a slower follow-up uses asynchronous execution, retains its invocation ID, and loads the result after an appropriate wait.

The employee assistant exposes narrow case operations through a Q Business custom plugin with JSON responses and explicit required fields. All write paths carry an application operation identity so Connect retries or repeated assistant requests do not create duplicate follow-ups. A department starting without Q Business evaluates Quick rather than attempting a new Q Business deployment.

Common exam traps

Attaching a separate Lambda function to every Lex V2 intent.
Treating filled slots as proof of an authorized CRM operation.
Returning prose instead of Lex’s required sessionState structure.
Applying Lambda’s general duration allowance to Connect’s 8-second synchronous block.
Treating asynchronous invocation as completed fulfillment.
Expecting AMAZON.QnAIntent to catch missed utterances during slot elicitation.
Assuming a plugin schema grants business permission or supports any REST response format.

What to remember

Match the adapter to each caller’s event and result contract.
Use Lex’s hook source and dialog action to control conversation state.
Respect Connect’s mode-specific waits and retain asynchronous invocation identity.
Expose narrow, authorized CRM operations through compatible plugin schemas.
Treat Q Business as an existing-customer integration boundary.