References and Connect resources

The two ways an item points at something else, why they behave differently, and how to see what depends on what.

Two field types point at something rather than holding a value. They look similar in the form and behave completely differently at runtime, which makes them worth ten minutes on their own.

Reference: pointing at another item

A Reference field is scoped to one entity when you define it. An experienceConfig field on Contact Source can only ever point at an Experience Config item, which is what stops the model turning into soup.

Look at the demo data to see it working:

  1. Open Contact Source and pick the item for one of the demo numbers.
  2. Its experienceConfig field points at an Experience Config item.
  3. Follow it. That experience points at a Prompts item, a Schedule, a Language and a Routing Destination.
  4. Follow the Routing Destination. It points at a Schedule of its own.

That is four levels, and a flow asking for the Contact Source path gets all of it in one answer, because DFC follows references before it replies.

A reference, resolvedJSON
{
  "data": {
    "address": "+15550100",
    "experienceConfig": {
      "name": "US Main Line",
      "routing": {
        "name": "NA General",
        "schedule": { "name": "Standard Business Hours", "timezone": "America/New_York" }
      }
    }
  }
}
Shared items are the point

The demo’s two experiences point at the same Prompts item and the same Closure item. That is deliberate: change the closure once and both lines shut. If you find yourself copying the same values into two items, you probably want one item and two references to it.

Connect resource: pointing at something in Amazon Connect

A Connect resource field points out of DFC entirely, at a real object in the Amazon Connect instance. When you edit one you get a searchable picker rather than a text box, and DFC stores both the resource’s name and its ARN.

The field is fixed to one kind of resource when the schema is written. The kinds available are queues, prompts, contact flows, flow modules, phone numbers and Lambda functions.

  1. Open Routing Destination and pick NA General.
  2. Its queue field is a Connect resource. Open it and you get a search over the real queues in the instance.
  3. Note that it stores a name as well as an ARN — the name is for humans reading the item, the ARN is what the flow uses.
An ARN is instance-specific

A queue ARN contains the instance it belongs to. Copy an item between instances and the ARN still resolves in DFC and still looks right in the portal, then fails at runtime when a flow tries to route to a queue that is not there. This is the single biggest gotcha when promoting configuration between environments.

Why the difference matters

Reference Connect resource
Points at Another DFC item A queue, prompt or flow in Amazon Connect
Kept in step by DFC, which follows it on every lookup Nothing — it is a stored ARN
Breaks when The target item is deleted The resource is deleted or the instance changes
A flow receives The whole target item, inlined The resource’s name and ARN

The practical version: a Reference is a live link inside DFC, and a Connect resource is a snapshot of something outside it.

Seeing what depends on what

Before you change an item, find out who is pointing at it. DFC tracks references in both directions, so an item can tell you what refers to it.

  1. Open the Prompts item that the demo experiences share.
  2. Look at what references it. Both experiences should be listed.
  3. That list is your blast radius. Changing this item’s welcome message changes both lines.
Deleting a referenced item

DFC will not silently orphan a reference. If an item is the target of one, deleting it is blocked or warned on rather than quietly leaving a dangling pointer in whatever referred to it. Check the reverse references first and you will never meet that dialog.