I was trying to build an option where I present the caller with the option 1 to speak to a CSR or Option 2 for them to enter their 6-digit account number.
I thought I could use Length in a decision object, but I am getting an error and I believe its because Length is looking for characters.
However, I've been looking to see if I need to use something more precise like toBool or toInt in order to use a decision object to validate if the caller entered 6-digits. In my test case I keep going down the false path.
So if I want to collect 6 digits with Option 2 and validate with a decision object that I have 6-digits captured (123456) to pass to a data or bridge action what would be the best function to use?
Short answer: try IsSet(Task.digits) and Task.digits == 6 as your expression in your decision action
Long answer:
The collect input data variable is a string, so the Length function can be applied to it. If the expression in your decision action is Length(Task.digits), then when you open the large expression editor
You will see a note that architect is using the ToBool function to convert an integer to a boolean. This is important because ToBool(X) returns true only if X is 0. Assuming Task.digits = "123456", Length(Task.digits) = 6 so ToBool(Task.digits) = false.
IF I wanted to create an in-queue flow to send the call to voicemail if a caller doesn't wish to wait and only send it to the user assigned the skill we discussed in the previous entry (above), is it possible to write an expression to do so?
We don't want it to be assigned as a static value to one agent (ie. transfer to user "alonso miller"), but perhaps route to the voicemail of the agent assigned the skill that the caller entered if they are not available...
I hope that made sense.
Yes there is a way to do that. First, in your inbound flow, add a set participant attribute action to save the agent's name (or email or id-something guaranteed to be unique). Do this prior to the transfer to acd action. In your in-queue flow, use the get participant attribute action to retrieve the agent's name, then use the parallel arrays approach to convert that string into a User variable. https://help.mypurecloud.com/articles/convert-string-value-typed-value/. That would allow to you to set the voicemail transfer target to the User variable.
Also I think your reply is for https://developer.mypurecloud.com/forum/t/can-you-use-a-webservice-to-determine-an-acd-skill-and-route-a-call/2054/2 instead of this thread. In which case if you use individual queues instead of individual skills for each agent, you don't need to go through the parallel arrays approach in the in-queue flow. You can just change the target type of the voicemail action to Queue instead of User and it will automatically go to the correct queue. I'm not trying to push one approach over the other, I'm just a fan of less typing.
If I use a get data wouldn't I need to add all of the agent's names' assigned in the queue in the get data object? When I read this at face value it makes me presume that I add the agent's name as a static value, so if the call is not for agent Joe and its for Agent Bob and I have the get data for agent Joe, then Bob would get the voicemail that is for originally agent Joe.
I am assuming I would have to make a list of all the agents in an array, is that a fair statement?
No, you do not need to add all the agents in the set participant data action, just the one the call is meant for. In the in-queue flow, you would create a collection of User variables, one for every agent in your organization. This would be similar to the Task.Queues variable in the documentation example. Then create a string collection of agent names; this would be similar to Task.QueueNames in the example. Make sure the order of the elements in these collections exactly match. You will also need to decide what to do if the agent's name fetched by the get participant attribute action isn't a member of your agent name collection (this would happen when a new agent is created but you haven't updated the in-queue flow yet, or there's a typo so the agent's name doesn't match the collection). Then use the expression in the documentation to figure out which User matches the string found by the get participant data action.
