Introduction

A contact flow is code, and anything you put inside it inherits the properties of code: it is edited in a flow editor, changed by whoever can edit flows, applied to that one flow, and shipped by publishing. That is the right home for logic. It is an awkward home for values.

DFC separates the two. The flow keeps the logic. DFC holds the values. The flow reads them at runtime through a single Lambda invocation, so a change takes effect on the next contact without touching the flow at all.

What that buys:

• The people who own the decision can make it. A closure is a form with a date on it, not a branch in a flow editor. And it needs DFC access rather than permission to edit flows, which is also permission to reroute every call in them.
• One change reaches every flow that asks. Ten flows reading the same path get the same answer. Held in the flows, each keeps its own copy and they drift, which is how a holiday reaches the main line but not the overflow one.
• A new entry point is a row, not another flow. Adding the fortieth number is adding an item. Changing all forty at once is a bulk edit rather than forty edits.
• A value change stops being a release. Editing a flow means republishing it, so a reworded prompt ships exactly like a redesign. In DFC the next contact simply gets the new value.
• Changes can be approved, and are recorded. Routing changes can carry an approval step, and the audit log says who changed which field and from what, rather than diffing exported flow JSON.
• The same configuration moves between instances. Export it from one and import it into another, so a test instance and production are configured from the same thing.

The flow still has its branches. What changes is that they stop being copies of each other.

The model in three words

Everything in DFC is one of three things. Get these straight and the rest of the workshop is detail.

Why a path and not a value

A flow does not ask DFC for a prompt. It asks for a path, and gets back everything hanging off that item, with every reference already followed.

That matters because contact centre configuration is a graph, not a list. A phone number points at an experience; the experience points at a prompt set, a schedule, a language and a routing destination; the routing destination points at a queue and its own schedule. One lookup walks the whole thing.

{
  "data": {
    "address": "+15550100",
    "channel": "voice",
    "enabled": "true",
    "experienceConfig": {
      "name": "Main Line",
      "enableLanguageSelection": "true",
      "promptSet": {
        "welcome": { "kind": "SSML", "content": "<speak>Thanks for calling.</speak>" }
      },
      "routing": {
        "name": "Sales Desk",
        "queue": {
          "connect_resource": {
            "name": "Demo Sales",
            "arn": "arn:aws:connect:us-west-2:111122223333:instance/a1b2c3/queue/d4e5f6"
          }
        }
      }
    }
  }
}

The flow asked one question and got the greeting, the language policy and the queue to route to. None of those values appear anywhere in the flow.

What you will build

The demo environment already has a working phone line. You will start by hearing it, then take it apart and build your own version of the same thing:

1. Call the line, see how the parts fit together, then change one value and hear the difference.
2. Create an entity of your own, with a schema, items, and references to other things.
3. Build a contact flow that reads your entity and plays a field from it back to a caller.
4. Compare it with the demo’s own flow, and change what that flow does without opening it.
5. Nest an entity under another, once the basics are behind you.

The first one comes within about fifteen minutes, on purpose. Everything after it is detail.