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.
- 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
We have a solution for this ask and have moved this on our backlog! Keep watching here for updates as we get closer to completing this work.
Rob Steenwyk commented
Definitely interested in this at my org, one of the things preventing a couple of our teams from switching from Slack.
Aaron Smith commented
Is there any update on this?
WALEED ABU YAHIA commented
I hope i can see this soon, honestly many industries and companies has a lot of regulations to host anything in cloud, like banking, nuclear, power. I think it is not a good idea from Microsoft to support only the cloud version, it looks like forcing people to use Azure. also If we take a look for other Bot framework they all support both. in my case i am stuck now and searching for other alternative rather than Microsoft Bot framework which I like a lot because of my company regulations which does not allow cloud computing. I hope if MS can specify a date when it will do it or if it will do it.
Nick Ellson commented
Would also like to see a simplified web socket / RealTimeMessage connection available to code bots against. Where might this be?
Stephan Hoermann commented
@Bill any update on this? Really interested to know when this might be available.
Bill Bliss commented
Sorry for the lack of response to this question - I just learned about it today. I head up the developer ecosystem for MS Teams.
We have some ideas on this that I will raise with you offline since I don't know how many of you check UserVoice regularly.
James McLachlan commented
Can anyone at Microsoft comment on whether there are any plans for this feature? One of the main potential blockers for us for Teams adoption is how we can integrate with our on-premise systems without the security concerns of allowing incoming connections via public URLs. I'm sure the various features available in Slack must have been looked at and considered as part of Microsoft's Teams planning so be great to hear their thoughts.
Brandon Olin commented
With Slack, this is accomplished with a websocket connection. This allows the bot to passively "listen" to conversations and trigger on certain messages. If that was an option in Teams, it would be pretty trivial to build bots against. Right now there is a fair amount of hoops to jump through to get a bot working. This makes it hard for companies interested in ChatOps to get an effort off the ground.
In my own project (PoshBot) (https://github.com/poshbotio/PoshBot) there is interest in supporting Teams as a backend. ChatOps bots are most useful when they act as an extension of your team and commonly require access to on-prem resources to do so.
Any update for this? No comments since July. To me the current model is little bit of a security hole. You have to have public facing interface that can be probed and must be maintained for security issues.
What is blocking this feature ? Is it a possible flood problem or lack of authorization ?
One solution I see for now is to have an authentication layer after publishing the bot, but not the best way obviously. Any communication on this? Is this even being considered?
Yes, please, on-prem bots are really necessary. I'd like to be able to have my bot talk to my jenkins server.
Currently we have applications that use the Slack API in order to listen to channels for commands, kick off application deploys, then respond in channel with the results. The current bot API makes this difficult as we would have to run a URL webservice which reverses our communication path. Rather than have Teams communicate with our URL, I'd like a process on my server to open a connection to Teams.
Brad Van Dorf commented
And allowing the bot to be in group chat in your channels so any of those notifications can go to a whole team of people and everyone can see that someone is working on the issue live where everyone can see how they fix something.
Michael Marks commented
This would be fantastic functionality to have to improve internal operations. As an example, we have an internal dashboard that displays where our traveling employees are on a day to day basis. This requires a lot of manual work and is often wrong because of it. Ideally our developers could create an internal bot that enables people to type something like, "@bot, I am in New York today." which then kicks off some code up update our dashboard with that users location.
Douglas Rockney commented
Note: Cog is looking for people who are interested in a bot for Teams so they can prioritize the work. Vote for the bot on their issue #1194 (https://github.com/operable/cog/issues/1194).
Olivier Jacques commented
Bot can be Hubot, Lita, Cog, ...
Without this, actual "ChatOps" kind of capabilities are not available.