The user workflow aggressively tries to prevent users from multitasking, despite many jobs requiring this.
Product design is a shining example of the greater Microsoft philosophy of forcing customers to adapt their business to Microsoft’s technology instead of having technology flexible enough to adapt to a customer’s business needs.
From an admin standpoint it has numerous questionable design decisions surrounding UC. For example, you can register non-Teams SIP phones to it, but you can’t see the IP addresses of these registered devices(?!). In general, from a telephony standpoint, Teams is good at providing dial tone and some very basic telephony features, enough to make senior leadership think that it does everything, but if you need UC functionality for more than users who sit at a desk all day it falls apart quickly.
My conversations with representatives from the product team at Microsoft suggests they are out of touch with how businesses use telephones.
To add to 2, it’s kind of like a chat platform built atop SharePoint. It’s so bizarre to try to dig into it from a bot/automation perspective. It’s like everyone complained how crappy it was trying to build business applications on to of SharePoint and felt compelled to prove those folks wrong even though they are pretty much right
And you didn’t even go into the network side of things, where Microsoft nearly forces you whitelist everything on the firewall, since they change like weekly, which IPs or URLs they want whitelisted, sometimes even going through third-party datacenters. And of course their documentation only gets irregular updates and can’t be easily parsed.
As an illustration of number 4:
When “upgrading” from on-site Sharepoint/Exchange to 365 it moves all group e-mail mailboxes to Teams accounts which makes it so group members can no longer send emails from that group’s address unless you restore the old method through a powershell command.
I work with Teams as an admin.
To add to 2, it’s kind of like a chat platform built atop SharePoint. It’s so bizarre to try to dig into it from a bot/automation perspective. It’s like everyone complained how crappy it was trying to build business applications on to of SharePoint and felt compelled to prove those folks wrong even though they are pretty much right
And you didn’t even go into the network side of things, where Microsoft nearly forces you whitelist everything on the firewall, since they change like weekly, which IPs or URLs they want whitelisted, sometimes even going through third-party datacenters. And of course their documentation only gets irregular updates and can’t be easily parsed.
Oh gods, I had forgotten what a pain in the ass that setup was and how it would just randomly stop working when they changed something on their side.
We had to change customer contracts to get this done, since the process for firewall changes was too slow…
As an illustration of number 4: When “upgrading” from on-site Sharepoint/Exchange to 365 it moves all group e-mail mailboxes to Teams accounts which makes it so group members can no longer send emails from that group’s address unless you restore the old method through a powershell command.