Allow on premise bots
By allowing bots which are hosted "on premise" (behind a company firewall), one allow to access systems from that company.
This is the situation for many companies where the infrastructure or services which need to be reachable by bots is not on the public internet.
Some scenarios:
- A bot is running behind a company firewall
- The bot connects to MS teams, joins a channel, and "listens" to conversations (outbound connection to the internet)
This enables interactions like:
- @bot, list defects (from an in-house issue tracker)
- @bot, add capacity to applicationx (after an authorization phase, on-prem application gets more servers for more capacity)
- [bot]> caution! applicationx experiences a 20% performance hit
Olivier Jacques
shared this idea
The feature team is still investigating this item and a decision has not been made yet.
-Warren
38 comments
-
J. Warwick
commented
For my company, it may not be as "critical" as it apparently is for others, but I can say that it would help drive adoption of Teams, and would allow us to deliver some internal services and get some more extensive integration with the MS business suite. We definitely have specific use cases where this would be a viable, maybe preferred UI.
-
Anonymous
commented
Come on Microsoft. This is a serious deficiency when competing with Slack.
-
Anonymous
commented
We need on-premises connectivity to bots to make Teams a ChatOps replacement for Hipchat. We are being forced to look at spending several hundred thousand dollars for Slack because Teams lacks a basic ChatOps feature. This is money we won't have to spend on other Microsoft services. Is there anything that can be done quickly utilizing Azure Application Proxies?
-
Anonymous
commented
Chat is for chatops. If I can't do this where I need to host a boy, there's no way this tool will become effective. Utterly necessary and a required feature. Please put this into the backlog and prioritize it!
-
Bernard
commented
Any news on this feature? We have bots that works upon Slack's RTM API (websockets) and it works nicely.
People can interact in a bi-directional way with processes hosted internally.
Head office is pushing Teams, but people are reluctant to use it, because internal bots cannot be ported over. -
Ben Raubenolt
commented
Pet peeve. In the context of "on-premises", premise is not the singular of premises. They are completely different words with different meanings. Shame on the lazy "journalists" that published some articles using cloud vs premise and made so many engineers looks stupid by copying them.
-
Brian Reid
commented
Seriously....2 years and you can't make a decision? Doesn't look good for a company that won't make a decision in 2 years or at least post it.
-
Anonymous
commented
This is what chatops is supposed to be. Make it happen MS!
-
Josh
commented
This would be great! Security probably wouldn't let us have it take inputs that can make changes on the network, but if we could have an internal bot that would report outages from within our intranet, and allow us to query that from within teams, it would be quite useful
-
Daniel Berber
commented
Same as everybody else here, we need websocket support.
-
Anonymous
commented
Any update on this guys? It is the biggest feature missing from the offering in my opinion and will scupper the Teams adoption effort in my current organisation (where we use Slack and it’s bot framework)
-
Anonymous
commented
Any update on this?
-
Magnus Hustveit
commented
On premise bots are needed for Infrastructure Chat Ops and security.
-
Karl Dietz
commented
Now that Teams is being offered for free and promoted as Slack alternative (at least in german press) can support for on-premise bots be revisited?
-
Kevin Stevenard
commented
@Warren, any update on this topic?
-
Olivier Jacques
commented
@Warren, having team chat and other Microsoft Teams capabilities without this is totally missing the ChatOps train. Should we look at hosting a mattermost or something equivalent in parallel for ChatOps use cases because MS Teams does not support websockets to allow on-premise bots?
There has been some discussions and even an Hubot adapter: https://github.com/Microsoft/BotFramework-Hubot
But this only support bots on the public cloud.We are looking for guidance.
-
Ryan Lancial
commented
We own Teams, and I’ve played around with pushing notifications via webhooks. Cool, but missing the websocket option and, by extension, ease of extensibility to support modern bot frameworks (thanks Brandon) has held me back in pushing more usage of the platform within the organization. There is so much that Teams does really well, this is the area I feel needs improvement.
-
Josh King
commented
I could have sworn that I'd left a comment on this a *long* time ago, ah well better late than never.
This is the ONE thing stopping our IT dept (and by extension our entire org) from adopting Teams as opposed to Slack. I've stood up a ChatOps POC in Slack and my team (no pun intended) is really keen to jump in full force but I'm putting the breaks on as I really want the platform we end up settling on being Teams... I mean it's part of what we're paying for after all.
At the moment we're at a cross roads, but I can't keep pumping the breaks on this for long. Eventually I'm going to have to give in and make a move. My fear is that this will end up being a move to Slack and at that stage we'll become entrenched on that service and it'll be a hard sell to transition over to Teams when it finally "catches up."
Appreciate the updates, and understand the technical hurdles. As an end user on the outside it's just frustrating that Teams didn't launch with feature parity compared to your biggest and most direct (imho) competitor.
-
Andrew Pla
commented
Yeah, this is a pretty big deterrent for us fully moving to Teams. I'd like to be able to fully embrace Teams and bots really enables us to adopt the product.
-
Warren F
commented
Same as Rob - Teams is a no go until websocket support or something comparable is in place.