I have looked everywhere I can think of and cannot find this answer. We are looking at creating a Profile with over 500 4 digit DNIS's. Is there a limit to how many 4 digit DNIS's you can have in one(1) profile?

I would suggest a handler that keeps them all in one easy place. An IP table with a quick handler lookup would be the best. Write me back if you want details. As for number, it is the total characters you can store in a registry key which I think is 16,383 characters.

Originally posted by RobertWC;32532
I would suggest a handler that keeps them all in one easy place. An IP table with a quick handler lookup would be the best. Write me back if you want details. As for number, it is the total characters you can store in a registry key which I think is 16,383 characters.

Thanks for the info Robert! We have a table already that has the DNIS, Skill, AppCode, Whisper msg, and priority. Today we have over 200 profiles and a whole lot of handlers. We are constantly moving or adding DNIS's around within the profiles. I wanted to create a Routing Profile. I would add the Attendant Profile Name to the current table. I wanted a way to migrate the existing DNIS's to this Routing Profile without having to put the DNIS's in the Routing Profile. That way the only place we had to change any DNIS is in the Table instead of in the profile and the table. I used 0000000001-9999999999 in the profile but it errored in the publish that the numbers already existed. I thought the hierarchy was exact match, range and wildcards. If I could get that to work, as they were ready in the table, migrate the DNIS in existing profiles to this Routing Profile by removing the exact match DNIS. Eventually all calls would go to one profile, read the table and route to the correct profile in the handler. We would have only One place to keep up with the 1,268 DNIS's and the group keeping up with these could do it when they wanted and not have to involve publishing. We are experiencing issuses with publishing so we have to do it once a week after hours. sorry for the wordy post...

You are almost there. Have the handler assign the routing to an attribute that you can use in an Attendant Selection tool to route to the other profiles. Also, use more dynamic values in your Attendant to reduce the number of profiles used.

Originally posted by RobertWC;32535
You are almost there. Have the handler assign the routing to an attribute that you can use in an Attendant Selection tool to route to the other profiles. Also, use more dynamic values in your Attendant to reduce the number of profiles used.

Thanks Robert, that sounds good for the handler but how do I get all the calls to go to the routing profile and leave the current 4 digit DNIS's in there current profiles until I am ready to remove them from the current profiles a few at a time. 0000000001-9999999999 did not work. Publish confict with DNIS in multiple places. Is this possible?

Use ???? or if that does not work 1???,2???,3???,4???,5???,6???,7???,8???,9???

[QUOTE=RobertWC;32543]Use ???? or if that does not work 1???,2???,3???,4???,5???,6???,7???,8???,9???[/QUOTE Sweet, I will give that a try! Thanks Master Robert! :)

Originally posted by DaleDel00;32544
[QUOTE=RobertWC;32543]Use ???? or if that does not work 1???,2???,3???,4???,5???,6???,7???,8???,9???[/QUOTE Sweet, I will give that a try! Thanks Master Robert! :)

Works! Thanks Robert! I owe you one.

Robert, I have a profile with ???? for the DNIS and it gets the call. Profile has one step, It calls the subroutine that routes the call to the profile identified in a table. This works and routes to the profile correctly. However, when the handler ends and returns to Attendant profile that started the subroutine, the call disconnects because I have disconnect call selected in the Attendant Subroutine Call. How can I terminate the handler and not return to attendant? OR even better is there a way I can do this in Attendant? THX

Make sure your subroutine sets p_bTransferred to false.

Originally posted by RobertWC;32566
Make sure your subroutine sets p_bTransferred to false.

Are you sure? I would have thought set it to true...

Try both. Never know which

Originally posted by RobertWC;32568
Try both. Never know which

Hey, I meant to tell you, It was 'true' and it worked. My default was false but I did not think to check it. Thanks! This will make it a lot easier keeping up with all the DNIS and they will be underquick edit, Table control. No publishing just to move a DNIS around or add a DNIS. Are you aware of any issues with 1400 DNIS going to one Profile with ???? as the DNIS selection? Logs, Reporting information changed? The DNIS is still the same just has a 'middle man' profile to route to the profiles. Thanks!

Not that I can think of aside from the registry field size. As for reporting, once the number is assigned as the local number, it only uses that number in all the SQL inserts. Now my CIC System Report handler would have a field day with that many in one profile. I'll have to test that. It will be like the other day when a customer tried it on 800 agents against 199 different licenses.

Originally posted by RobertWC;32576
Not that I can think of aside from the registry field size. As for reporting, once the number is assigned as the local number, it only uses that number in all the SQL inserts. Now my CIC System Report handler would have a field day with that many in one profile. I'll have to test that. It will be like the other day when a customer tried it on 800 agents against 199 different licenses.

That makes a lot of sense. Should the registry be out of the picture now since we will be taking all 1400 DNIS out of the profiles? All the profiles will contain now is a single Name in the Profile DNIS selection Ex:(Mob_ContractEntry). All calls will go to the MasterRoutingApp containing '????,??????????'. All calls will hit this Profile. The MasterRoutingApp profile runs a handler that reads a table that matches the DNIS to a column in the table with the name of the Profile DNIS selection in it(Mob_ContractEntry). Using 'Get Profile' in the handler it will route the call. We ran some test and it works great but fear it may affect reports or any logging issues by searching for an exact match accross the profiles. You know if anyone has done this before and their pitfalls, if any?