Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Setting User Defined Attributes in the Customer Hold Flow

0

Hi Community

I'm experiencing some unexpected behaviour when setting User Defined Attributes within the Customer Hold flows. Whenever customer is placed on hold, we have a Set Attribute block in place to update User Defined Attributes in the flow, which allows us to track use of hold and customise customer journeys later in their end to end journey via call handling. eg, during the call transfer process. As part of this, we set the name of the agent who placed the caller on hold and the queue the call was being handled on when it was placed on hold. Previously, this worked perfectly fine and always reflects the details associated with the last agent/queue the caller was placed on hold with. However, recently this behaviour stopped working in our Test Instances. Within this instance, we note that regardless of the number of call transfers or which agent the call in placed on hold by (1st, 2nd, 3rd etc) the use of hold throughout the various stages is always reflecting the original agent/queue the contact was initiated with and the contact logs always show the hold events against the original contact ID.
This only occurs in the Test Instances though, our production instance still behaves perfectly and the Customer Hold flow (and use of it) always reflects against the correct agent/queue who placed the customer on hold. All contact flows used in test and prod are like for like (they are exported and imported, and we have redeployed to ensure this).

Would anyone have experience of this and understand what may be causing the difference?

  • David Macias
    a year ago

    With these I am always going to say user error. If you export your PROD scripts to DEV, same issue? Are both instances in the same region?

  • HLKenny
    a year ago

    @dmacias - Yes, both instances are in the same region. Production flows were actually exported from test env (which was previously fine). Flows have been exported back to testing instance, from Production, but still the results continue to be different in test instances versus production. The logs for the test instance calls show different information from production. In production, we can see the call flow information for the use of hold against the 2nd call (ie, with the agent that took over the call). However, in test instance there are no log for the use of hold against the 2nd call. The use of hold for the 2nd, or 3rd call, when transferred, show against the original call... and the flow behaviour is acting as expected. The issue appears to be due to this... AWS is continuing to associate the use of hold in the 2nd and 3rd calls against the original contact ID and the original contact ID information (agent, queue). Where as production does not do this.. So, the question is what configuration option would possibly be responsible for that behaviour?

Topics
Application IntegrationManagement & GovernanceBusiness ApplicationsMachine Learning & AINetworking & Content Delivery
Tags
Amazon ConnectAmazon CloudWatch
Language
English
asked a year ago321 views
2 Answers
1
Accepted Answer

Hi all... For anyone looking at this post, I've figured out what the problem is.

The issue relates to the the difference in how the call is managed when multi-party calling with enhanced monitoring is enabled versus not.

answered a year ago
-1

The issue you're experiencing with User Defined Attributes in the Customer Hold flows in your Test Instances is unusual, especially since your Production instance is working correctly. This discrepancy suggests that the problem may not be in the flow configuration itself, but rather in how the attributes are being set or accessed.

Here are a few things to consider:

  1. Attribute Scope: Make sure you're setting the attributes on the "Current contact" and not as "Flow" attributes. Flow attributes are temporary and restricted to the flow in which they are configured, while attributes set on the current contact persist throughout the contact's lifecycle.

  2. Attribute Names: Verify that the attribute names you're using in the "Set contact attributes" block are consistent across all flows and instances. Even small differences in capitalization or spacing can cause issues.

  3. Lambda Functions: If you're using any Lambda functions to process or modify attributes, ensure they are behaving consistently across both environments.

  4. Queue Configuration: Double-check that the queues in your Test Instances are configured identically to those in Production, including any associated routing profiles.

  5. Agent Workspace Configuration: Ensure that the Agent Workspace in your Test Instances is set up correctly to display these attributes.

  6. Contact Flow Versions: Confirm that you're using the most up-to-date versions of all contact flows in both environments.

  7. Instance Settings: Review the settings of your Test Instances to ensure there are no configuration differences that could affect attribute handling.

  8. Logging and Monitoring: Enable detailed logging for your Test Instances and monitor the logs to see exactly how and when the attributes are being set and accessed.

If the issue persists after checking these points, you may want to create a minimal test case that reproduces the problem and reach out to AWS Support for further assistance. They can help investigate any potential backend issues or recent changes that might be affecting your Test Instances differently from your Production instance.

Remember, when working with contact attributes, it's crucial to set them correctly and reference them appropriately in your flows to ensure they persist and update as expected throughout the customer journey.

Sources
Flow block in Amazon Connect: Set contact attributes - Amazon Connect
Amazon Connect - Show View System Attributes | AWS re:Post

answered a year ago
AWS
SUPPORT ENGINEER
revised a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content