Contact Flow ARN Parameterizer

How to move Amazon Connect contact flows between accounts

Queue, prompt, flow and hours-of-operation IDs are different in every Connect instance, so a flow exported from dev can't be imported into prod as it is. This is the end-to-end workflow:

1. Export the flow from the source instance (flow designer → Save → Export flow), or run aws connect describe-contact-flow. Both formats work here. To move several flows that call each other, use Batch: several flows so every flow shares one mapping.
2. Parameterize. Every ARN becomes a named placeholder such as {{Queue_Sales}}. Names come from the display names stored in the export, and you can rename any placeholder. Instance IDs, account numbers and phone numbers found outside ARNs (for example in contact attributes) are listed so you can parameterize them too.
3. Describe the target. Enter the target account, region and instance, then paste the output of the AWS CLI list commands (list-queues, list-prompts, list-contact-flows, list-contact-flow-modules, list-hours-of-operations, lambda list-functions). Copy the CLI commands gives you the full set to run in CloudShell. Save the target as an environment (for example prod) so the next flow needs no setup.
4. Match. Each placeholder is matched to the target resource with the same name and type. Lambda functions and Lex V1 bots with the same name are retargeted to the new account and region automatically. Anything that can't be matched is highlighted, and you pick it from a list or type the value.
5. Build and check. Build target JSON substitutes every value, updates the display names in the flow layout data so the designer shows the right names, and checks that no placeholders are left and that every ARN points to the target account, region and instance. A before/after table shows each change by block. Check in Flow Validator then runs the full pre-import checks.
6. Deploy. Import the JSON in the flow designer, or download the CloudFormation template: each flow becomes an AWS::Connect::ContactFlow (or ContactFlowModule) resource whose content uses !Sub. Each placeholder is a template parameter, defaulted to the matched target value. Flows in the same batch that transfer to each other are linked with GetAtt instead of parameters.

Everything runs in your browser. The flow and the resource lists are never uploaded, and saved environments stay in your browser's local storage.

Promoting flows from Dev to Prod: a worked example

Most teams run at least two Amazon Connect instances: one for development and testing, one for production, often in separate AWS accounts. Flows built in Dev contain ARNs that only exist in Dev. This walkthrough shows how to turn an exported flow into a reusable template and deploy it with CloudFormation.

Step 1: Export and parameterize

Export the flow from the Dev instance and paste it here (or load the Basic Queue + Lambda sample). The tool finds every ARN (queues, prompts, Lambda functions, Lex bots, hours of operation, other flows) and replaces each one with a named placeholder such as ${QueueSupportArn} or ${LambdaCustomerLookupArn}. Identical ARNs share one placeholder, so a queue used in five blocks becomes one parameter.

Step 2: Use the template in CloudFormation

The parameterized JSON fits CloudFormation's Fn::Sub directly:

Resources:
  MainInboundFlow:
    Type: AWS::Connect::ContactFlow
    Properties:
      InstanceArn: !Ref ConnectInstanceArn
      Name: Main Inbound
      Type: CONTACT_FLOW
      Content: !Sub
        - |
          { ...parameterized flow JSON... }
        - QueueSupportArn: !GetAtt SupportQueue.QueueArn
          LambdaCustomerLookupArn: !GetAtt CustomerLookupFn.Arn

Queues, hours of operation and prompts can be created in the same stack and referenced with !GetAtt, so the flow always points at resources that exist in the account it is deployed to. For resources managed elsewhere, pass the ARNs in as stack parameters, one parameter file per environment.

Step 3: Re-hydrate for a quick manual import

Not using infrastructure as code yet? Use the Re-hydrate section to enter the Prod ARNs for each placeholder and download import-ready JSON for the Prod console.

Pitfalls that catch people out

• Lambda association. A Lambda function must be associated with the instance before a flow can invoke it. In CloudFormation use AWS::Connect::IntegrationAssociation, and make sure the function's resource policy allows connect.amazonaws.com to invoke it.
• Flow-to-flow references. If the main flow transfers to a module or another flow, deploy the target first, or create both in the same stack so CloudFormation resolves the order.
• Prompts are not portable. A prompt ARN references audio stored in that instance. Upload the same audio to each environment (AWS::Connect::Prompt supports an S3 source) and parameterize the ARN.
• Phone numbers. Numbers are claimed per instance and associated with a flow separately. They do not travel with the flow JSON.
• Region in the ARN. If Dev and Prod are in different Regions, the region segment differs too. The tool treats the full ARN as the value, so region differences are covered.

Suggested CI/CD layout

flows/
  main-inbound.json          # parameterized template (from this tool)
  customer-queue.json
params/
  dev.json  test.json  prod.json   # ARNs / stack parameters per environment
template.yaml                # queues, hours, prompts, flows, Lambda associations

Store the parameterized JSON in Git so flow changes go through code review. Diff two versions with the JSON Comparison Tool, and validate them with the Flow Validator in the pipeline before deploying.

Official references

• AWS::Connect::ContactFlow (CloudFormation)
• AWS::Connect::IntegrationAssociation (CloudFormation)
• Import and export flows