Not sure why you'd have it do that, but if it's certain days it needs to go to the other part of the script, you could have a Day of Week switch in the menu with a different GoTo. Otherwise, if you need to manually change it and you want to do that without getting into the script, you could set a boolean variable as a Paramater. That way, you can just go to the application in UCCX and change it there instead of having to get into the script and make changes, save, and reload the app.

Sounds to me like you have a planning problem
What I would actually recommend doing before you go any further is sit down with your customer, get every last detail of what they'd like you to build, make a Visio drawing of the call flow including the verbiage of the prompts, and have them sign off on it. Then from there, any changes out of the scope of work are a minimum of 1 hour paid time (more if it takes you longer to change the script as requested) for you.

Thanks Johnathan/Steve
Jonathan,
Agreed, But this is something that I will be building as a product and then presenting it. So here need to develop this even befoer the customer asks for this.
Steve,
In this case will i not be restricting my self of the options or i need to have all permutations and combinations in the if block as i suppose in case of UCCX you can execute only 1000 steps (runtime) So i will run out of this considering the fact i need to include my features (e.g. Recent Activity, ...). Hope i got what your point.
What i was thinking is will form the call flow using a java code and then for every active option (DTMF) will map a script so if DTMF 1 is for RecentActivity then will return relevant script if DTMF 1 is Transactions then return relevant script name and use a subflow to jump to these scripts which would be already there.
Seems the above approach may work and may give a better dynamism, But need to work out on this.
Let me know if there are any other optimal ways to achieve the same.
Binny

I got your point. But do let me know if you have any suggestions on how to achieve this.
 
Also how can we increase the steps as in one of my recent project i got an exception regaring this and then we had to do some work around on that.
 
Binny

Hi
From your earlier description, you basically want to have a number of available 'actions', based on 'inputs' which will be DTMF digits. You want to be able to change the flow 'at runtime', but you've not described what factors should change that other than suggesting that tomorrow it might be different. 
To do that you basically need to give the customer the option to press a digit, and collect it in a variable. You would then use that input digit to look up a mapping of some sort - that could be:
- Against a parameter on the script
- Against a database
- Against an XML file
- Any of the last two above could have their values modified either through a management script (telephone interface based or web if you have premium) or through whatever means you like. If it's simply going to change based on day of the week, then you can again set that up as part of the lookup data in any of those methods.
So for example, user presses 1, you look up 1 against your XML file and that tells you that the action is 'recent transactions'. Script has
IF returnvalue == "recent transactions"
true: goto 'recenttransactions'
Perhaps if you can detail what you requirements actually are there will be a better way of designing this. The point is that you only have so many 'things' you can do, and you only have so many potential inputs from a phone, you just need to map the two externally.
This isn't something that is commonly done, as generally the prompts you play to a user will be prerecorded - e.g. press 2 for recent transactions. There are ways around that as well, of course..
 
Aaron