Victor,
It's always a challenge when you move from one platform to another - especially if you are competent and comfortable in the old one!
Regarding dependency searches. There are many use cases. If you have a Queue that is directly referenced in a flow, and you delete it, the flow will then report an error. Also, prior to deleting it, you can do a dependency search to verify it is not in use. If you dynamically allocate as a result of a DB dip, then the actual queue isn't referenced directly and not only will you not be able to see it, but the flow won't show an error (trust me, this can be a PITA to locate since the error won't occur until the flow is executed!) What if you are planning to edit a flow that is called from others (very common!) How can you verify that it isn't being called from somewhere unexpected (thus causing unforeseen issues) without a dependency check?
Now, you may argue that you know your design. You know to check this Database or that Data Table, but someone new coming in to support the system (say you win the Powerball and leave!) won't know all of that.
Trust me, having taken over several systems where extensive (excessive?) use of Data Tables / Databases to configure everything from Queues and Skills to Schedule Groups and Prompts, it's an absolute nightmare to navigate and, on more than one occasion, it was more cost-effective to simply start again from scratch!
Whilst these kinds of approaches can appear cool and effective, and once understood may impress others with their efficiency, I have found that they usually lead to added complexity and make the system harder (and thus more expensive) to support overall.
I believe the KISS principle applies here 😉
------------------------------
Paul Simpson
Eventus Solutions Group
------------------------------
Original Message:
Sent: 08-09-2023 23:56
From: Victor Shvetsky
Subject: Sample Flow where IVR prompts and routing is read from a variable
Hi,
I am not seeing a lot of value in dependency search. Clearly this is due to my lack of full comprehension of what it can offer. Creating variable-based queue names, targets, and IVR announcements would cut down on number on workflows and pretty much everything else. Visually maybe it iis going to be hard for a casual user, but overall it seems as a better way to manage, especially if 80 percent of the worklflows are similar. Obviously, I am not seeing something since there are two posts both mentioning this.
------------------------------
WE SUPPORT UKRAINE
Original Message:
Sent: 08-09-2023 14:34
From: Paul Simpson
Subject: Sample Flow where IVR prompts and routing is read from a variable
Victor,
You can certainly do that. The various operations that utilize those objects accept an expression as well as a literal. There are functions like FindQueue() that can be used to get a Queue ID given a Queue name and so on.
However, I should warn you that doing this can make flows much harder to troubleshoot. The dependency viewer will become almost useless to you and you will find yourself writing a lot of this to Participant Data so you can trace what happened.
HTH
------------------------------
Paul Simpson
Eventus Solutions Group
Original Message:
Sent: 08-09-2023 00:26
From: Victor Shvetsky
Subject: Sample Flow where IVR prompts and routing is read from a variable
Hi,
is there a way to create a flow to do a DB dip and then assign IVR announcement and Queue and Skill on the fly?
In the Genesys Engage and prior versions, you could call commands similar to RouteDN and pass along the parameters on the fly. This way, instead of having hard-coded flows, you could have one flow where we could assign its IVR, Queue and Skill when the call enters it based on ANI, DNIS and so on. I spent an hour looking for these objects in Architect and cannot figure out where they went. Can someone please help?
Thank you!
#Routing(ACD/IVR)