Skip to main content

Using Disconnect Flow Re-queue with SCCAC

Overview​

AWS Connect's default Sample Disconnect Flow supports automatically re-queuing contacts when customers reply within 15 minutes of disconnecting. This allows customers who disconnect during a messaging session to resume their conversation without losing their place in the queue.

To use this re-queue functionality with SCCAC messaging, you must add SCCAC components to the disconnect flow. Without these modifications, the re-queued contact will not be properly presented to agents in Salesforce Omni-Channel.

When to Use This Configuration​

Use this configuration when you want to:

  • Allow customers to resume messaging conversations after disconnecting
  • Maintain the customer's queue position when they reconnect
  • Enable seamless conversation continuity in Salesforce

Prerequisites​

Before customizing the disconnect flow, ensure you have:

  • Completed the Setup Messaging configuration
  • Reviewed the Sample Inbound Flow documentation
  • Access to Amazon Connect instance with appropriate permissions to create and modify contact flows

The components used in this configuration follow the same pattern as documented in the Sample Inbound Flow section. Refer to that documentation for detailed configuration parameters.

Step-by-Step Instructions​

1. Copy the Sample Disconnect Flow​

  1. Log in to your Amazon Connect instance
  2. Navigate to Routing > Contact flows
  3. Locate the Sample disconnect flow
  4. Choose Save as to create a copy
  5. Give it a descriptive name (e.g., "SCCAC Disconnect Flow with Re-queue")

2. Modify the Flow​

When a contact is re-queued, the previous messaging session has ended. SCCAC needs to create a new messaging session record in Salesforce and link it to the contact.

Before the Transfer to queue block, add the following blocks in sequence:

Step 1: Invoke Create Messaging Session Lambda (REQUIRED)​

Add an Invoke AWS Lambda function block for CreateMessagingSessionFunction:

  • Follow the configuration in Sample Inbound Flow, Step 2
  • This lambda creates a new messaging session record in Salesforce for the re-queued contact
  • When successful, the lambda returns three values:
    • conversationIdentifier: The conversation identifier in Salesforce for the newly-created Conversation record
    • workItemId: The Salesforce record identifier for the MessagingSession record
    • source: Set to "SCCAC" to mark the contact as originating from SCC-AC

Why This Is Required: When a messaging session ends and the contact is re-queued, SCCAC needs a new messaging session record in Salesforce to present the work item to agents in Omni-Channel.

Note: The channelAddressIdentifier attribute is already inherited from the original contact, so you do not need to set it again.

Step 2: Set Contact Attributes (REQUIRED)​

Add a Set contact attributes block to store the values returned from the CreateMessagingSessionFunction lambda:

  • This corresponds to the pattern shown after the lambda invocation in the Sample Inbound Flow
  • The lambda automatically stores its return values as contact attributes (conversationIdentifier, workItemId, source)
  • These attributes link the new messaging session to the contact so SCCAC can present it to agents in Salesforce

Purpose: Ensures the new messaging session ID and related information are properly associated with the re-queued contact.

Step 3: Invoke Routing Lambda (OPTIONAL)​

Add an Invoke AWS Lambda function block for RoutingFunction (only if needed):

  • Follow the configuration in Sample Inbound Flow, Step 3
  • Only add this if you want the routing configuration for the re-queued contact to differ from the original routing configuration

Note: If the contact should route using the same configuration as the original inbound flow (same queue or Omni-Flow), you can omit this lambda invocation.

3. Add Error Handling​

Following the same pattern as the Sample Inbound Flow:

  • Add retry logic around the lambda invocations using looping constructs
  • Configure error branches to handle lambda failures
  • If lambda invocations fail after retries, disconnect the contact

Important: If the CreateMessagingSessionFunction lambda fails (error branch), it won't be possible for the contact to be offered to agents in Omni-Channel, and the contact should be disconnected. Follow the error handling pattern in the Sample Inbound Flow to surround the Invoke AWS Lambda blocks with looping constructs, allowing the API calls to be retried multiple times before disconnecting the contact.

4. Save and Publish​

  1. Choose Save to save your changes
  2. Choose Publish to make the flow active
  3. Update your queue or routing profile to use the modified disconnect flow

Flow Structure Example​

Your modified disconnect flow should have this structure before the Transfer to queue block:

  1. Invoke AWS Lambda → CreateMessagingSessionFunction (REQUIRED)
    • Creates new messaging session in Salesforce
    • Returns conversationIdentifier, workItemId, source as contact attributes
    • Success branch → Continue to next step
    • Error branch → Retry loop or disconnect
  2. Set contact attributes → Store the new messaging session information (REQUIRED)
    • Attributes are automatically set by the lambda response
    • Links the new session to the contact
  3. Invoke AWS Lambda → RoutingFunction (OPTIONAL)
    • Success branch → Continue to Transfer to queue
    • Error branch → Retry loop or disconnect
  4. Transfer to queue → Routes the re-queued contact

Testing the Configuration​

To verify your disconnect flow works correctly:

  1. Initiate a test chat contact
  2. Have the contact routed to an agent
  3. Agent accepts the contact and ends the messaging session
  4. Within 15 minutes, send a new message as the customer
  5. Verify the contact is re-queued and presented to an agent in Omni-Channel
  6. Verify a new messaging session record was created in Salesforce
  7. Verify the conversation history is maintained in Salesforce

Reference Documentation​

Important Notes​

  • The 15-minute re-queue window is configured in the default AWS Sample Disconnect Flow and can be adjusted if needed
  • The channelAddressIdentifier attribute from the original contact is already inherited, so you only need to create the new messaging session and set its attributes
  • The required blocks must be added before the Transfer to queue block in the sequence shown above
  • This customization applies to AWS Connect's default flows and is separate from SCCAC-provisioned contact flows
  • Each re-queued contact creates a new messaging session record in Salesforce if the previous messaging session has ended
  • If you modify the timing or logic of the disconnect flow, ensure these required blocks remain before the transfer block in the correct sequence