At its simplest, you can use an Excel sheet as a "database" with a Query activity in a workflow. We have this for a customer where they have ~100 sites but all have the same options. The database has three columns, site name, DNIS and ring group. When the caller chooses the option to speak to their local branch, the query looks up the DNIS they dialled and transfers them to the value in the ring group column. The site name column isn't used in the query, it's just documentation. [Someone can jump in here and say that passing untrusted data to a database query is an exploit waiting to happen, but meh]. Before we moved to a database lookup, the workflow was awkward to navigate at only 30 sites, and the workflow editor in YSE isn't the slickest of software even at the best of times!
You can probably achieve the above with Rules rather than an Excel "database", but the customer liked the idea of being able to make a bulk change by substituting a different spreadsheet.
When you say hunt groups, extensions and workflows...YSE certainly lets you arrange things in a variety of different ways, but the way I do this to economise on port usage is, there are a pool of messaging ports, messaging ports belong to one or more hunt groups, and each hunt group has a workflow attached to it. Any one port can belong to multiple hunt groups. Yes, you can assign ports directly to workflows but I am not sure if this is the "right" way.
From your description, I don't
think you need 43 hunt groups, you could have just one hunt group with every DDI pointed at it, branching based on DNIS. Branching to what, though? Different schedules, different messages...I'm sure if you spent long enough you could build this into a workflow using variables, database reads/writes, dynamic RADs [
http://micc.mitel.com/kb/KnowledgebaseArticle51476.aspx ] and subroutines. The key to keeping this manageable is making each site as similar as possible, but if the customer is accustomed to every site being different then you're going to have a hard job rowing back, especially if the only reason is to make your life easier :-)
Perhaps start with a new workflow and add sites to it one by one, building up the complexity. Or maybe don't bother and try and be "clever" on the next project with a greenfield site.
In case you weren't aware, there is a large amount of diagnostic information about a call's progress through a workflow in <MiCC directory>\Logs\Devices\<port number>.log. Add all the ports to Real Time > Port Monitor in CCC to see which port you've hit. You can open all the port logfiles in Baretail. Also, every version of a workflow you've ever saved is kept as an XML file in <MiCC directory>\Ivr\Workflow\Compiled.
The main thing I think MiCC workflows are missing is that there is no obvious way to send a call to a mailbox from a workflow. Seems like a bit of an oversight.
