(upbeat music)
- Hello, I'm Adrian Solis,
a principal software engineer on Teams platform.
I lead a group of developers
who work with partners building apps for Teams.
You may have seen us on GitHub,
Stack Overflow, email,
maybe you've read our blog posts
and sample code.
Or perhaps you work with us directly at Hackathons
and other partner events.
- And I'm Erin Bailie.
I'm an ecosystem PM on Microsoft Teams.
And I work with partners who are writing apps
to go into the team store,
I help them with the full lifecycle of app development
from envisioning, development
and marketing launch.
We're gonna talk about the app development process.
And we'll take you through the four phases
of app development,
envisioning your app,
implementing it, debugging it,
and then publishing it.
Lastly, we'll share some resources and tips
for writing and publishing an app in Teams.
Before we get to the first stage in app development,
which is envisioning,
we should talk about apps in Teams.
An app in Teams needs to have at least one item
from each column in this slide.
Apps need to have a capability,
and they need to work in a scope.
Lots of apps in Teams
have more than one item from each column.
But instead of telling you more about these,
let's take a look.
I'll show you an app called Contoso.
We'll start by talking about Bots.
Bots let you get things done
as a team or on your own.
They can post information proactively to a channel,
and they can respond to queries.
Here, we see a Contoso Bot has posted to a channel
and a user has sent a request to get more information,
in this case, a list of the team's tasks.
Next on our tour are tabs.
This is a Contoso tab.
It's been pinned to a channel.
All the users in the channel have the same view
of this project board,
and they can have a conversation about what they're seeing.
But each user's personal project list may be different,
which is why personal tabs are useful as well.
Here, we have a user's personalized Contoso tab,
and it shows all of their tasks across different projects.
Next is an example of a message extension.
A user is searching for information in Contoso.
And they insert an adaptive card,
an actionable containerized UI element
to post into the channel.
So far, we've shown you the channel and personal context.
And we've shown you tabs, bots,
and message extensions.
In our last example, let's look at meetings,
which are an extension of group chats.
Here's the Contoso app in a meeting.
You can see that the meeting organizer
can view a few polls to send out
over the course of the call
and see the responses as they come in.
Now that we know the basic construction of an app in Teams,
we can get to the development process,
which starts with envisioning.
When you're deciding to build an app in Teams,
start by defining the scope
and the scenario that your app will cover.
Ask yourself, who are the users I want to empower?
And what workflows do I wanna bring to Teams?
Focus on solving real world relevant problems.
Think about broad impact for many users.
Try to focus on solutions that have a high impact.
You could try to reduce the mean time to resolution,
or cut down the bug count.
These are a few goals that Teams apps can help solve.
Once you know the scenarios,
you can create the app model that fits those scenarios.
Have a collaborative scenario,
put it in a channel
or a meeting context.
Is it something for personal productivity?
Use a personal app.
Think about the durability of the information
shown in your app as well.
Is it a temporary view?
You could use a task module UI element,
but if it's something that should be searchable
or discoverable in the long run,
try using a tab
or adaptive card in the chat.
- So after you've considered your apps close
and selected the capabilities
that you're targeting for your app,
you're probably eager to start building.
If you've worked on a Teams app before,
you're already familiar with how these capabilities work
and are ready to start implementation.
On the other hand, if you're just getting started,
I recommend that you experiment first
and try out some samples to validate your plan.
Either way, it's best to begin with a quick start
to generate the starter code for your application.
Now at build this year,
we announced the Microsoft Teams Toolkit extensions
for Visual Studio and Visual Studio code.
You can install them from these links on screen,
or through the extension managers of each IDE.
We have a range of samples in our Docs page
and in the Bot framework samples repo,
check them out.
They're especially helpful
if you're looking for a code snippet
that demonstrates a specific technique,
like implementing a task module,
may be a messaging extension
or sending a proactive message to a set of users.
And if you're looking for full end to end examples
of solutions built on Teams,
I recommend that you look at our catalog of app templates.
These apps implement entire scenarios,
and they're ready for you to deploy and try out.
We have about 30 of them in our catalog right now.
And we're building more.
We include doc detailed documentation for them,
and we hope that makes them good starting points
for you to customize further.
Another reason to use the toolkits
for generating a scaffolding for your app is that,
they pull in the right base set
of libraries in SDKs for you.
For instance, when you create a tab app
with Visual Studio Code Toolkit,
you'll find it includes the Teams JavaScript library,
which is a prerequisite for all iframe content inside Teams,
like tabs, pass modules,
and connector configurations.
It also includes the fluent UI react components,
which are set of components for react that are styled
like the ones that we use inside Teams itself.
These two libraries are what you'll use
when developing hosted experiences inside Teams.
Now if you were to generate the starter code for a bot
or a messaging extension,
the toolkit will include the corresponding SDK
for the Microsoft Bot Framework.
This SDK is available in various languages.
The .NET, JavaScript and Python SDKs
are ready for production release.
While the Java SDK is in development
that's currently in preview.
We also have libraries that help you use Microsoft Graph.
If you use this,
note that there's a separate one for graph endpoints
that are still in Beta.
So when you're taking advantage of these API's,
remember, they include the Beta version
of the SDK inside your application.
So sign in is a significant friction point for any app.
We see users drop off
when presented with a sign in prompt
and we've worked hard to streamline the process
with single sign on for tabs.
And soon also for bots.
We recommend that you take this further
and make the auth experience pretty smooth for your app
by sharing user information between its functions.
Now although as Erin explained,
that Teams app is composed of individual capabilities,
like bots, tabs, messaging extensions,
and perhaps graph integrations as well,
but to the user, it's just one app.
So we encourage you to share information
between these functions
and capabilities to present a unified front.
The common key that's available
across all these capabilities
is the user's tenant ID
and Azure AD object ID.
So this is the key that you should use
when storing information about the user.
In your tab or task module,
use SSO to get an access token for the user,
which on your server,
you'll validate and examine
the tid and oid claims to get the tenant ID
and object ID respectively.
This process is even easier for bots
and messaging extensions,
because every activity sent to your bot
includes this information automatically,
so you can get it directly from the payload.
When designing and implementing your app,
it's helpful to consider
the different kinds of Teams users
that your app will encounter.
The first most common kind of user
is one who is a member of an organization
that uses Microsoft 365.
And who is using Teams inside their own organization.
Now when they are invited to be a guest
in a team that belongs to a different org,
they become a guest user there,
even though they still log in with their username
and password from their home tenant,
note that the guest identity
is effectively a new user in the other tenant.
You'll see it different object ID
and user principal name for this user.
If you need to distinguish between guests
and regular user,
what you can do is ask Graph
for the user details,
because guests will have a user type property
that indicates that they are a guest
and not a user.
And with the new meeting extensibility apps,
you'll start seeing a new user type
anonymous meeting participants.
These are participants who joined the meeting
from a meeting join link,
and who didn't sign in to Teams.
They exist only for the duration of the meeting.
And you'll see that they're unique
and that they don't have a corresponding entry
inside Azure AD.
So if you ask app about them,
you won't get an answer at this point.
If you're creating an app
that's meant to be used for meetings,
please be aware of these anonymous participants.
And consider all of these types.
Think about what each user types should
or should not be allowed to do
inside your application.
And remember to test this scenarios.
One more thing.
When signing in to the Microsoft identity platform,
we recommend that you always
use the tenant specific endpoint shown above.
This endpoint handles both organizational
and guest users correctly,
and returns a token for your intended tenant,
which is typically the one
that the user is currently signed into.
Whether they're a regular user in that tenant,
or a guest user from a different organization.
We see some apps use a common endpoint,
which has a string common
instead of the tenant ID.
Now using this endpoint will sign in guests
and Teams free users to the wrong organization.
And that leads to failures
during the app validation process.
Speaking of app validation and authentication,
a cardinal rule that we check during validation
is that apps that implement sign in
must also provide a way to sign out
or disconnect from their service.
This slide here has an overview
of the recommended way of presenting this option
to the user,
which depends on the capability as you can see.
Basically, if the user can sign in through your bot,
they should also be able
to disconnect through a bot command.
Users interact with Teams apps in different ways.
Some people might use a bob bade prefer to use a bot,
or they may, others may prefer to use a tab.
And it's often is orienting to allow
signing in through one capability,
but then only allow logging out
through a different one.
Now, a final note on logging out,
if you use the Microsoft identity platform
as your authentication provider,
please be careful
not to use the size single sign-out endpoint
when signing out of a tab.
Remember that Teams itself uses Azure AD.
So triggering a single sig-out
will make the user to log out of Teams too,
which is often not what you intended.
In this case, we recommend that
you clear all this data on your server,
and state on the local machines such as cookies,
local storage and indexedDB content,
and start afresh the next time
that the user visits your tab.
Now let's talk a bit about debugging.
When I develop apps for Teams,
there are a few must have tools
that I find absolutely indispensable.
First is the reverse proxy.
So I can run bots and tabs locally.
These are tools like ngrok,
or the Tunnel Relay project
that we publish on our GitHub repo.
And they let me debug my app
inside Visual Studio
or Visual Studio Code
while it's running on my machine.
Now you can debug your app
while it's running on the cloud up in Azure.
I've done that.
But trust me, it's faster to do it locally.
Now, ngrok, and Tunnel Relay
also have nifty interfaces
that show you the requests received by your app,
and your app response.
Even if you use the Bot Framework SDK,
I will encourage you to occasionally take a few minutes
to learn look at the raw JSON payload as well.
Sometimes it has information in there
that that you may not know existed
because we've relied too much on IntelliSense
or on the, the models provided by the SDK.
And it's interesting to take a look
at what the what your bot actually ends up receiving.
A web debugging proxy
like Fiddler or Charles is another useful tool.
This kind of proxies are complement
of the reverse proxy,
while ngrok shows you the incoming requests,
Fiddler will show you the outgoing ones.
When I see an error in a bot
while it's sending a message,
or even when in Teams
while I'm uploading something like a package or a manifest,
I turn to a tool like Fiddler.
We've improved the error messages
returned by our services.
And often the response content
of the request is fail
is enough for me to figure out
what happened and fix it.
The browser Dev Tools window
is also handy during debugging.
This window lets you see the JavaScript console,
check cookies, local storage,
indexedDB contents,
and basically inspect
and manipulate your pages DOM,
among other things.
Now, if you didn't know,
you can bring up this window
in the Teams desktop client,
and also in the Teams Android app
by following these instructions in our doc pages.
- All right, you've built your scenarios,
and you're ready to test out your app
and deploy it to users.
First, you should decide
how you're going to deploy your app.
If you're testing locally,
or if you only want to deploy to one organization,
you can have a Teams admin
upload the app as a line of business app
through their admin portal.
However, we always encourage
publishing to the Teams App Store.
You'll get exposure
to the over 75 million daily active users of Teams,
and you'll enjoy easy discovery
and management of the app through the team store
and the partner center.
Should you choose to publish globally?
You'll do so through the Microsoft partner center,
and your app will be listed in app source
and the team store.
Start by checking out the Teams developer documentation
for checklists
and automated checkers for your app
to ensure that it's ready for submission.
Then, use the partner center
to submit your app for validation and publish.
Give our team at least two weeks to validate
and set up the regression testing for your app.
And once they're done,
your app will be live in the store
and ready for users.
- We hope that this was a good intro
to the process of envisioning
and building a Teams application.
And then you picked up some helpful tips and techniques.
Here's some other content
and resources that you'll find useful.
There's a need guidebook at aka.ms/buildTeamsappguide
that dives deep into designing,
building and publishing an app for Microsoft Teams.
Also, please download
and use the Visual Studio extensions
that I mentioned earlier at aka.ms/Teams-toolkit-vs.
And aka.ms/Teams-toolkit.
Finally, there's a ton of interesting content here
at Ignite, please check them out.
We highly recommend these ones on screen
as they relate beautifully
with the topics that we just covered today.
- Lastly, thanks for joining us today.
We hope you enjoy the rest of your sessions at Ignite.