UCCE - IVR variables exchange

[ronin2k8cronus]

Hi guys,

I belive this time I have kind of a silly question but considering I have little experience with UCCE and I only have a live environment, I will go ahead and ask it.

My question is related to "enterprise call variables" more precisely "Call.CallerEnteredDigits and Call.PeripheralVariable1 to Call.PeripheralVariable10". Some of this variable are used in a UCCE and a IVR script. Can I use the same variables like Call.CallerEnteredDigits and Call.PeripheralVariable1 in a different UCCE and a different IVR script or will their usage in new scripts will affect the old scripts.

Example : I have a UCCE script that calls an IVR script. The IVR script is a plain play prompt. The prompt that is played is taken from the Call.PeripheralVariable1 which is initiated in the UCCE script. Can I use different UCCE script to call the IVR play prompt script, but the prompt that will be played be initialized in this new UCCE script. By doing this I use two different UCCE script that initialize the Call.PeripheralVariable1 with diffrent values when calling on the IVR script. Is it possible to do this or is there a restriction saying if you use "Call.CallerEnteredDigits or Call.PeripheralVariable1 to Call.PeripheralVariable10" inside a script then you can not use it for new scripts?

Thanks for all the help.

Silviu.

[Anthony Holloway · Accepted solution]

Those variables, as the name implies (call dot) are on a call by call basis.

Think about it like this.  Each caller gets 11 variables (CED + PV1-10) for you to store data about them for the duration of the call.  If you store "banana" in PV1 for caller 1 and "orange" in PV1 for caller 2, there would be no conflict at all.

Like wise, if you stored "banana" in PV1 in Script 1, and "orange" in PV1 for Script 2, there would be no conflict.

Now, with that said, you have to keep in mind how your using these variables.  for example: If you are showing PV1 & 2 to the CTIOS desktop, and the column headers are: "Customer Number" and "Customer Type", and you store "banana" in PV1, you will confuse the Agent.  But this is not a funciton of how PV's work, but more a limitation of how you're implementating PV's.  Hopefuly you have the PV usage documented somewhere, where it says which ones are reserved and for what purpose.  Likewise, if you have reports based off of PV's.  E.g., You look for call records where PV1 == "12345" for customer with number 12345.

If I can offer one more example to drive the point home: if you were to create a brand new Dialed Number, Call Type, ICM Routing Script, and IVR Script, you could use the PV's however you like without affecting the existing programming of the scripts.  This is because they are per call, as the name implies (call dot).

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Gergely Szabo · Accepted solution]

... just my 50 cents: there are also global ("user") variables in ICM. Global means they are visible, both for read and write, from all the scripts. It's easy to confuse call attached variables (PeripheralVariables1..10 + ECC ones) and global ones. I have seen many cases when the engineers tried to use global variables instead of call attached ones, leading to unexpected behaviour .

G.