Who is responsible for reviewing the bot publication and how long does they take to review and approve my bot?
There is a large backlog of bots currently being reviewed by the Bot Framework team. It's worth noting however, that the only thing that this approval does is to include your bot in the official Bot Framework directory. You do not need your bot reviewed by the Bot Framework in order to be live on any of the channels.
That being said, many of the channels have their own review processes (such as Facebook, Kik, Slack, etc.) Some (like Facebook) require review before any 3rd party can contact your bot. Others (like Slack and Kik) require review to list in their directory or auto-complete in #mentions. You'll need to apply for review from each of these channels.
Your bot already is live and your friends can use it; you just have to share the join link with them for the chat service you want them to use (look in the embed codes section). The bot directory just lets you share it more broadly than friends.
Related
We want to easily add our custom bot to the conversation window when an user ping us. Currently we have to upload the zip file of the bot to the conversation every time. Ideally the bot should be found by searching in the "Add People" - just like how the real people been added. Several questions:
I noticed that the custom bot can be published. However, we don't want it to be published publicly, it needs to be Microsoft internally. Is it possible?
If the bot got published, can we add the bot to a conversation just by searching in the "Add People" box? If not, is there anyway to achieve this?
Thank you!
If you want to publish the bot for your organisation only, you can publish it in your tenants app catalog. You need to be a global admin or have the teams service admin role enabled to publish apps for your organization.
Publish apps in the Microsoft Teams Tenant Apps Catalog
As far as I know, this isn't possible yet. However when people search for your bot in the topbar, they can add the bot to a team or to their personal workspace.
my organization was using Slack, and decided to move to Google Hangouts Chat. I used channels to coordinate with different teams. How do i migrate these users to Hangouts Chat rooms?
(Issue) Chat rooms allow duplicates, and are created private. So new users cannot see them & join. They end up creating copies of a similar common room each time.
Either of the following kinds of options are fine with me.
Export users list email-addresses from my Slack channel. Import these users into Chat as #email-id . I can't seem to get the email-list from Slack
Send Chat room shareable invite link to channel users. Google Chat rooms don't give shareable invite link.
As Erik said, the operation you are looking for is users.list. Though you need to ensure you have users:read and users:read.email set in your environment. This will also give you a bunch of empty entries though, as it will include all bots and apps on your workspace, which do not have emails.
I wrote a quick app using Transposit (disclaimer: I work for them) that you can fork here that will return an array of all valid emails in a Slack organization for you. Authenticate with Slack, and it should work by just running get_emails.js.
Unfortunately, we do not yet have a Hangouts connector, so we can't automate the whole process through this app, but I hope you find it helpful! Let me know if you have any questions in a DM, or message us at support#transposit.com.
Best,
Griffin, Developer Advocate at Transposit
Question: How to have multiple bots supplying answers to the same Teams chat window a user has with an aggregator bot.
Description:
Several different teams have created bots that can answer questions related to their areas. Picture a services bot, a catalog bot, etc. All of these bots are maintained by their individual area owners, have their own sets of LUIS intents, etc. That works great, but you have to know where to look for each type of question.
Now we'd like to have a single bot for anyone to connect to, to get their questions answered no matter what area the question falls into. The idea is that this aggregator bot would then forward the questions to the appropriate area bot, which would then provide the answer. The scenario here is that someone troubleshooting an issue could ask questions crossing multiple areas in the same place without having to know about each individual area's bot.
The bots are currently hosted in Teams and are C#. So far, our solution has this flow:
Aggregator bot receives the question and asks each bot (through another endpoint specific to this flow) how confident it is that it can answer the question.
Aggregator bot decides which bot(s) to ask the question to, and sends the question off to the regular /api/messages endpoint for the bot.
[Broken] Area bot posts the answer/ auth prompt if needed/ or the start of a conversation to clarify the eventual answer.
We found the bot-to-bot handoff project, but in the readme.MD, it says:
Note: The main bot and each of the sub-bots share the same AppID and
AppPassword. This allows all the bots to share the same conversation
ID, Dialog
Stack,
and Bot State
Data.
This is not possible in Azure, because you can't create multiple bots with the same AppId.
Trying a hack based on that, we found that if we change the bot configuration to use the same MicrosoftAppId and MicrosoftAppPassword in the Application Settings in Azure for all the bots, then everything works fine through the aggregator bot. At that point, you can no longer connect directly to the individual bots anymore. While that is clearly a hack and not a solution, it implies that the problem is authentication based and not something that is implicitly impossible.
There are lots of pieces around that seem like they might help, but we haven't found the documentation to fit them together. This seems like something that should be a common scenario. Ideally we could specify some kind of bot trust at a higher level and not have to specify AppId and AppPassword directly, though we're willing to do that in this case since we're all the same company.
Things we've tried:
Using TrustServiceUrl to trust the aggregator bot from each area
bot, and all the area bots from the aggregator bot. The call was
made in Application_Start in Global.asax for each bot.
The hack described above
Specifying AppId and AppPassword in the BotAuthentication attribute
Number 3 actually solved the auth problem for letting the aggregator bot ask each bot for it's confidence in answering the question when we used it to tag those functions. Specifying the AppId and AppPassword for the aggregator bot in the specification for that endpoint in the individual area bots worked great. But it didn't fix the ability for the individual area bot to post back to the conversation owned by the aggregator bot. In that case, the aggregator bot itself is consuming the answer, and it is an answer and not a flow.
What do we try from here? Is there something we've missed, or is there something fundamentally wrong with the approach we've started with?
I recently built a slack bot via the BotKit toolkit and now want to be able to expand from just slack to many other services. Basically, I was reading https://venturebeat.com/2016/11/02/how-bots-will-work-on-microsoft-teams/
and it states that
"The integration means Microsoft Bot Framework users will be able to make bots for Slack, and Botkit users will be able to bring their bots to additional platforms, like Telegram, Kik, Twilio, and Skype. (Before the change, Botkit was only able to make bots for Slack and Facebook Messenger.)"
However, it is not clear to me how this can be accomplished. Do you mind explaining this to me or pointing me in the right direction? From what I understand, it should be a simple process of having my slackbot basically run within Microsoft Teams or Skype or whatever service.
Thanks!
The VentureBeat link for the Public Preview of Microsoft Teams was referring to the ability to use bots written for Slack (via BotKit or otherwise) within Microsoft Teams with little or no modification necessary. This capability is provided by Message.io. You can contact them for more information or look on their website.
Microsoft Teams also has a native bot platform - the Microsoft Bot Framework (which also supports Slack, Skype, Facebook, and several other chat platforms). BotKit does not yet support Bot Framework.
(#JasonSowers)[https://stackoverflow.com/users/3011564/jasonsowers] is correct - BotKit and Bot Framework are two different bot platforms; today Microsoft teams supports one via Message.io and one natively.
So I think your path is:
Register your bot in the Bot Framework to host the bot, referencing the Botkit. Make sure you add Microsoft Teams as a channel.
Create a package for your bot and [Sideload it][3] in Teams to test.
I have been trying to publish my Skype bot to Microsoft Bot Directory, it has been almost two weeks and it is still in review.
My questions are:
Do they have a list of must haves for the bot so that they can only accept it if it fulfills these requirements? They didn't reject mine either but I will be prepared in advance in case they do.
If yes where can I find this info?
Has anyone here submitted their bot and how long did it take for them to be published?
Thank you
I submitted a few months ago and it is still not approved.
The bot directory is very selective and they won't approve you unless it's a full fledged mature application.
Plus, they also claim that their reviewing resources are very limited.
I'd say don't expect to get approved.
And no, they don't have any kind of requirements.
Here are a few items that might help with guidance:
MICROSOFT BOT FRAMEWORK– PREVIEW ONLINE SERVICES AGREEMENT
Bot review guidelines
Developer Code of Conduct for the Microsoft Bot Framework
It takes a few days (maybe a little longer) to get a response from a review. A couple items that caught me off guard were their logo requirements, which are very precise, and the welcome/help message needs to be complete. You also need to specify your Terms of Use and Privacy Policy well. Looking at these documents, there are probably several more items that are likely to trip-up submission.