I think it's quite funny that you call the idea of simply using the MiCollab Client "convoluted" and then you come up with a plan involving building a web portal and poking commands into bits of the Mitel applications to achieve what is done so very simply from the MiCollab client.
Using the MiCollab Client, users initially simply create statuses reflecting how they want their Multi-Device User Group to behave, eg,
An "In the office" status that rings their deskphone
A "Working from Home" status that rings their softphone
An "On the Road" status that rings their mobile AND softphone
An "In a meeting" status that rings their voicemail
A "Send everything to Bob" status that sends all their calls to Bob
etc....
This is a one-time config to create each status, unlike call forwarding where you have to reconfigure the target number for each different scenario every single time
Then all they have to do in the MiCollab Client is flick between statuses according to need. They can run the client on their desktop/laptop or mobile.
Also, they can configure their Client to use their Outlook calendar statuses to change their MiCollab status automatically, eg,
"Busy" - change MiCollab to "In a Meeting"
"Out of Office" --> "Send Everything to Rob"
"Working Elsewhere" --> "On the Road".
Yes, MiCollab is convoluted - for the end-user. All of the options you listed above are perfectly valid, but presume that our users have set those up ahead of time. The self-service portal was a bit convoluted for us to setup initially, in that it took literally three hours of coding and testing and from then on we never needed to get involved ever again, and our users could add, change, remove call forward destinations by clicking on a single link and entering a number. Compared to that MiCollab is *extremely* convoluted, if they get to a meeting and realise that the call forwarding destination they have configured to send calls to their colleague won't work, because that person has called in sick - now they need to login to the MiCollab client and add a new destination and/or create a new status, then change to that status. And changing those numbers is many more clicks and menu options away than our existing offering, which would not only require us to provide more training, but will lead to more support tickets and will also lead to greater user frustration.
Consider it from our users point of view - previously, to divert their phone to any number or extension, they just clicked on a link, typed in a number and hit submit (ignoring their ability to also do this from phones - this portal is more for the "Oh crap, I totally forgot to divert my phone before leaving the office" situations). Now we're having to say "Oh, we've changed all that - now all you need to do is log into this app, click on Settings, click on My Numbers, click the ellipsis at the top right, click +New, add in a label, add in the number, Click Add, then click on Manage Status, then click on the ellipsis at the top right of *that* pane, click +New, enter a Status Name, change Send my calls to [the number you just typed in], then click Done. THEN, all you have to do is change to that status whenever you want to divert to that number. It's really simple really and so much better than the old system and who cares if you had to spend five minutes in that meeting you were already late for because it's sooo much better"
I was only asking because we've been able to come up with a simple method for our users to reset their passcodes - which there is literally no 'Mitel' way of doing without knowing the previous passcode, which kind of defeats the object because that's the main reason people would need to reset them - so was wondering if there was a similar function we could hook into to replicate our existing end-user approved system. And FYI, that user-passcode reset portal did take more effort - nearly a whole morning to put in place!
But this is clearly a system limitation of Mitel coupled with our pre-existing applications rendering what is clearly a core component (MiCollab) redundant, so we'll just have to put up with it I guess.
Thanks for responses, even if they were a bit unnecessarily condescending and completely ignored the fact we're not rolling MiCollab out...