What happens if a caller doesn't press any digit during GetParticipantInput's Timeout window?

The flow falls through to whatever DefaultAction is configured for that action's Conditions, if no DefaultAction is set, the flow's behavior in that no-input case is undefined/problematic, essentially a dead end for the caller. Always set a sensible DefaultAction (routing back to the menu with a retry limit, or to a general queue) for any GetParticipantInput action, don't assume every caller will press a valid key within the timeout.

Does a contact flow support looping (like retrying an IVR menu on invalid input)?

Yes, a Transitions.DefaultAction (or a Condition) can point back at the same action's Identifier, creating a loop, this is a valid and common pattern for 'invalid input, please try again'. The risk is an infinite loop with no exit for a caller who keeps failing to provide valid input, well-designed flows track retry count and eventually route to a fallback (a general queue or voicemail) after a few failed attempts rather than looping forever.

Can multiple contact flows reference the same HoursOfOperationId?

Yes, HoursOfOperation is a separate Connect resource referenced by ID, multiple contact flows across your Connect instance can reference the same hours-of-operation definition, meaning updating business hours in one place (the HoursOfOperation resource) automatically reflects across every flow using it, rather than needing to update hours logic independently in each flow.

AWS Connect Contact Flow Builder

ServerlessAWS

Build Connect contact flow configurations with IVR menus, queue routing, hours checking, and participant actions.

Amazon Connect Configuration

Build Connect contact flow configurations with IVR menus, queue routing, hours checking, and participant actions.

Required Fields

NameTypeInstanceIdContent.StartActionContent.Actions

{
  "Name": "customer-support-inbound-flow",
  "Description": "Main inbound contact flow with IVR menu and queue routing",
  "Type": "CONTACT_FLOW",
  "InstanceId": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "Content": {
    "Version": "2019-10-30",
    "StartAction": "play-greeting",
    "Actions": [
      {
        "Identifier": "play-greeting",
        "Type": "MessageParticipant",
        "Parameters": {
          "Text": "Welcome to Acme Support. Your call may be recorded for quality assurance."
        },
        "Transitions": {
          "NextAction": "check-hours"
        }
      },
      {
        "Identifier": "check-hours",
        "Type": "CheckHoursOfOperation",
        "Parameters": {
          "HoursOfOperationId": "hours-of-operation-id"
        },
        "Transitions": {
          "Conditions": [
            {"NextAction": "ivr-menu", "Condition": {"Operator": "Equals", "Operands": ["True"]}},
            {"NextAction": "after-hours", "Condition": {"Operator": "Equals", "Operands": ["False"]}}
          ]
        }
      },
      {
        "Identifier": "ivr-menu",
        "Type": "GetParticipantInput",
        "Parameters": {
          "Text": "Press 1 for billing, press 2 for technical support, press 3 to speak with an agent.",
          "Timeout": 5,
          "MaxDigits": 1
        },
        "Transitions": {
          "Conditions": [
            {"NextAction": "route-billing", "Condition": {"Operator": "Equals", "Operands": ["1"]}},
            {"NextAction": "route-tech", "Condition": {"Operator": "Equals", "Operands": ["2"]}},
            {"NextAction": "route-general", "Condition": {"Operator": "Equals", "Operands": ["3"]}}
          ],
          "DefaultAction": "ivr-menu"
        }
      },
      {
        "Identifier": "route-billing",
        "Type": "TransferToQueue",
        "Parameters": {
          "QueueId": "billing-queue-id"
        }
      },
      {
        "Identifier": "route-tech",
        "Type": "TransferToQueue",
        "Parameters": {
          "QueueId": "tech-support-queue-id"
        }
      },
      {
        "Identifier": "route-general",
        "Type": "TransferToQueue",
        "Parameters": {
          "QueueId": "general-queue-id"
        }
      },
      {
        "Identifier": "after-hours",
        "Type": "MessageParticipant",
        "Parameters": {
          "Text": "We are currently closed. Our hours are Monday through Friday, 8 AM to 6 PM Eastern. Goodbye."
        },
        "Transitions": {
          "NextAction": "disconnect"
        }
      },
      {
        "Identifier": "disconnect",
        "Type": "DisconnectParticipant",
        "Parameters": {}
      }
    ]
  },
  "Tags": {
    "Department": "customer-support"
  }
}

Generated Output

Output will appear here...

About This Tool

Build an Amazon Connect contact flow as a graph of Actions (MessageParticipant, CheckHoursOfOperation, GetParticipantInput, TransferToQueue, DisconnectParticipant) linked via Transitions, either a simple NextAction or Conditions branching on the previous action's result. GetParticipantInput's DefaultAction matters more than it looks: if a caller doesn't press a valid digit within Timeout seconds (or presses an unmapped digit), the flow falls through to DefaultAction rather than erroring or hanging, and a contact flow missing that fallback (or looping back to the same menu indefinitely without a max-retry escape) is a real, easy-to-ship caller-experience bug, not just an edge case.

When to Use This Tool

•Branching on CheckHoursOfOperation's boolean result to route to a live ivr-menu during business hours versus an after-hours message and disconnect outside them, driven by a centrally-managed HoursOfOperationId rather than hardcoded time logic in the flow itself.
•Setting a DefaultAction on GetParticipantInput's Conditions so a caller who doesn't press any key within the Timeout, or presses an unmapped digit, gets routed somewhere sensible (often back to the menu, or to a general queue) rather than the flow simply stalling.
•Structuring TransferToQueue actions by department (billing, tech support, general) so IVR menu selections map directly to the correct staffed queue, keeping call routing logic centralized in the flow rather than requiring downstream logic to redirect.
•Including an explicit DisconnectParticipant action at every terminal path (after the after-hours message, for instance), so the flow always has a defined ending rather than leaving a caller connected with nothing left to do.

Pro Tips

TIP

Every GetParticipantInput action needs an explicit DefaultAction, a caller failing to press a valid digit within the timeout with no default configured is a real, reproducible bad-caller-experience bug that's easy to miss in testing if you only test the happy path of pressing valid digits.

TIP

A menu-retry loop needs a bounded retry count with an eventual escape to a human-reachable fallback, an unbounded loop traps a caller who, for whatever reason (bad connection, wrong expectations), can never get past the IVR menu.

TIP

Centralizing hours-of-operation and queue routing IDs as referenced resources (rather than hardcoding logic per-flow) means operational changes (holiday hours, a new queue) update in one place and automatically apply everywhere they're referenced.

How It Works Under the Hood

The builder validates that Name, Type, InstanceId, Content.StartAction, and Content.Actions all resolve before accepting the JSON as a valid contact flow definition, the fields Connect needs to know the flow's entry point and its full action graph; it can't verify every Identifier referenced in a Transitions.NextAction actually exists among the listed Actions, or that referenced QueueId/HoursOfOperationId values are valid in your Connect instance, those checks happen only when the flow is published against the live instance.

Frequently Asked Questions

What happens if a caller doesn't press any digit during GetParticipantInput's Timeout window?: The flow falls through to whatever DefaultAction is configured for that action's Conditions, if no DefaultAction is set, the flow's behavior in that no-input case is undefined/problematic, essentially a dead end for the caller. Always set a sensible DefaultAction (routing back to the menu with a retry limit, or to a general queue) for any GetParticipantInput action, don't assume every caller will press a valid key within the timeout.
Does a contact flow support looping (like retrying an IVR menu on invalid input)?: Yes, a Transitions.DefaultAction (or a Condition) can point back at the same action's Identifier, creating a loop, this is a valid and common pattern for 'invalid input, please try again'. The risk is an infinite loop with no exit for a caller who keeps failing to provide valid input, well-designed flows track retry count and eventually route to a fallback (a general queue or voicemail) after a few failed attempts rather than looping forever.
Can multiple contact flows reference the same HoursOfOperationId?: Yes, HoursOfOperation is a separate Connect resource referenced by ID, multiple contact flows across your Connect instance can reference the same hours-of-operation definition, meaning updating business hours in one place (the HoursOfOperation resource) automatically reflects across every flow using it, rather than needing to update hours logic independently in each flow.

Related Learning Guides

Lambda Performance Tuning26 min read
SQS vs SNS vs EventBridge25 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.

AWS Connect Contact Flow Builder

ServerlessAWS

Build Connect contact flow configurations with IVR menus, queue routing, hours checking, and participant actions.

Amazon Connect Configuration

Build Connect contact flow configurations with IVR menus, queue routing, hours checking, and participant actions.

Required Fields

NameTypeInstanceIdContent.StartActionContent.Actions

Generated Output

Output will appear here...

About This Tool

When to Use This Tool

•Branching on CheckHoursOfOperation's boolean result to route to a live ivr-menu during business hours versus an after-hours message and disconnect outside them, driven by a centrally-managed HoursOfOperationId rather than hardcoded time logic in the flow itself.
•Setting a DefaultAction on GetParticipantInput's Conditions so a caller who doesn't press any key within the Timeout, or presses an unmapped digit, gets routed somewhere sensible (often back to the menu, or to a general queue) rather than the flow simply stalling.
•Structuring TransferToQueue actions by department (billing, tech support, general) so IVR menu selections map directly to the correct staffed queue, keeping call routing logic centralized in the flow rather than requiring downstream logic to redirect.
•Including an explicit DisconnectParticipant action at every terminal path (after the after-hours message, for instance), so the flow always has a defined ending rather than leaving a caller connected with nothing left to do.

Pro Tips

TIP

How It Works Under the Hood

Frequently Asked Questions

What happens if a caller doesn't press any digit during GetParticipantInput's Timeout window?: The flow falls through to whatever DefaultAction is configured for that action's Conditions, if no DefaultAction is set, the flow's behavior in that no-input case is undefined/problematic, essentially a dead end for the caller. Always set a sensible DefaultAction (routing back to the menu with a retry limit, or to a general queue) for any GetParticipantInput action, don't assume every caller will press a valid key within the timeout.
Does a contact flow support looping (like retrying an IVR menu on invalid input)?: Yes, a Transitions.DefaultAction (or a Condition) can point back at the same action's Identifier, creating a loop, this is a valid and common pattern for 'invalid input, please try again'. The risk is an infinite loop with no exit for a caller who keeps failing to provide valid input, well-designed flows track retry count and eventually route to a fallback (a general queue or voicemail) after a few failed attempts rather than looping forever.
Can multiple contact flows reference the same HoursOfOperationId?: Yes, HoursOfOperation is a separate Connect resource referenced by ID, multiple contact flows across your Connect instance can reference the same hours-of-operation definition, meaning updating business hours in one place (the HoursOfOperation resource) automatically reflects across every flow using it, rather than needing to update hours logic independently in each flow.

Related Learning Guides

Lambda Performance Tuning26 min read
SQS vs SNS vs EventBridge25 min read

Was this tool helpful?