How a lookup works

The three moving parts behind that call, and the path a request takes through them.

You have heard the demo line. Before changing anything, it is worth knowing what answered you.

DFC is three things: a store holding the configuration, a lookup function that reads it, and the contact flow that asks. The CX Portal is a fourth, writing to the same store.

How a DFC lookup flows

A caller reaches an Amazon Connect contact flow, which invokes a Lambda function with a path. The function reads DynamoDB and returns the resolved item, which the flow stores as contact attributes. Separately, the CX Portal writes to the same DynamoDB tables.

At call timeWhenever someone editsCallerdials the numberContact flowAmazon ConnectLambda functiontakes a pathDynamoDBtablesthe configurationstoreCX Portalsomeone edits an itempathreadresolved itemwrite

One call, step by step

  1. The caller dials. Amazon Connect starts the contact flow.
  2. The flow builds a path from something it already knows, such as the dialled number, and invokes the lookup function with it: /Contact Source/+1555….
  3. The function reads DynamoDB, follows the references it finds, and returns one resolved object with the referenced items inlined.
  4. The flow stores what came back as contact attributes and branches on them: which prompt to play, which voice, which queue, whether to transfer at all.
  5. Nothing else in the call touches DFC.

Why a change is immediate

The portal and the contact flow meet at the same tables. The portal writes an item; the next call reads it. There is no build, no deploy, and no cache in between, which is why the change you make in a later module is audible on the very next call.

One lookup per contact, by design

The flow asks once, early, and stores the answer. Calling the function again on each branch would work, but it adds latency to every leg of the call and makes the function’s concurrency scale with how complicated the flow is rather than with how many calls you take.