►
From YouTube: Microsoft Graph community call – May 2021
Description
This month's community call features presentations on Application Consent Deep Dive (demystifying permissions and consent when accessing Microsoft Graph) and on Considerations for Creating Online Meetings (Integration into Outlook or into other 3rd party experiences). Q&A in this call after demos, at end and in chat. The call was hosted by Brian T. Jackett (Microsoft) | @BrianTJackett. Microsoft Presenters were Philippe Signoret and Fabian Williams. This call was recorded on May 4, 2021.
Stay connected:
• See the full blog post for this call at - https://aka.ms/m365pnp/community/blog
• Twitter - https://twitter.com/microsoft365dev, @Microsoft365Dev
• YouTube - https://aka.ms/M365DevYouTube
• Blogs - https://aka.ms/M365DevBlog and https://aka.ms/m365pnp/community/blog
• Recurrent Invite to this community call - https://aka.ms/microsoftgraphcall
• All Microsoft 365 developer community calls – https://aka.ms/M365DevCalls
A
Good
morning,
good
afternoon,
good
evening,
everyone
this
is
the
microsoft
graph
community
call
for
may
of
2021..
Today,
we've
got
some
great
content,
we'll
be
going
through
app
consent,
deep
dive,
as
well
as
a
little
bit
about
considerations
for
creating
online
meetings
within
microsoft.
Graph.
Today
we
have
a
fleet
and
fabian
will
be
joining
us
due
to
the
presentations.
A
There
is
our
agenda
quick
note.
If
anyone
is
interested
in
presenting
in
the
future,
we
do
accept
community
contributions,
so
welcome
anyone
who
has
wanted
to
share
information
about
solutions,
you've,
built
or
potential
different
topics
related
to
microsoft.
Graph,
if
you
are
interested,
feel
free
to
reach
out
to
myself
or
jeremy
brian.jacket
at
myself.com
or
jeremy.fake
at
microsoft.com,
feel
free
to
include
the
information
down
at
the
bottom
on
here.
B
So
today
I
want
to
talk
a
little
bit
about
api
permissions
and
consent,
in
particular
when
it
comes
for
permissions
and
consent
for
access
to
microsoft
graph
and
rather
than
do
what
we've
done
other
times,
which
is
sort
of
just
show
you
how
you
use
msel
or
the
graph
sdk
to
to
request
the
token
and
get
access
I
wanted
to
take
it.
Maybe
a
step
back
and
sort
of
talk
about
some,
some
more
general
concepts
around
authorization
for
applications
accessing
apis
in
general
and
specifically
microsoft
graph.
B
So
some
of
the
topics
that
we're
going
to
cover
today
is
basically
just
in
general
how
apps
and
services
can
access
microsoft
graph,
which
will
lead
us
to
two
of
these
authorization
flavors,
which
is
application
permissions
and
delegated
permissions
we'll
go
over
the
concepts.
Some
of
the
ways
in
which
permissions
can
be
requested
we'll
go
over
some
of
the
ways
in
which
permissions
can
be
granted,
and
then
I
think,
most
importantly,
we'll
talk
about
sort
of
some
of
the
aspects
regarding
to
how
much
data
these
permissions
grant
access
to
and
what
alternatives
we
have
for.
B
Restricting
the
the
set
of
data
the
permissions
give
access
to
so
just
to
very,
very
broadly,
whenever
an
app
or
a
service
needs
to
access
data,
let's
just
say
in
general,
through
an
api.
There
are
two
ways
in
which
this
data
can
be
accessed.
Two
ways
in
which
that
the
microsoft
identity
platform
explicitly
supports
one
of
them
is
what
we
call
direct
access.
The
the
application
is
is
not
there's
no
user
involved.
The
application
is
just
directly
going
and
going
to
try
to
perform
an
action.
B
Read
the
data
download,
a
file,
create
a
file
update,
a
user
reset,
a
password,
etc.
That's
one
flavor
direct
access.
The
second
flavor
is
and
indirect
access
the
api,
so
microsoft
graph.
If
you're
calling
microsoft
graph
is
going
to
ask
just
one
question
in
terms
of
authorization,
and
the
question
is:
is
this
app
authorized?
B
B
The
other
form
is
when
the
application
is
not
doing
what
we
call
direct
access,
it's
actually
accessing
on
behalf
of
a
user.
We
also
call
this
sometimes
delegated
access
or
apple's
user
access.
That's
why,
in
this
diagram,
there's
a
user
and
an
application
on
the
left
and
then
the
api
is
on
the
right
and
the
little
token,
if
you,
if
you
notice
the
pentagon
in
the
middle,
is,
is
the
user
right,
because
the
the
the
thing
that's
identified.
B
That's
making
this
request
is
the
user,
and
so
the
first
question
is
not
is
the
app
authorized?
The
first
user
is
actually
is
the
user
authorized,
and
so
that
question
that
first
question
on
both
sides
is
actually
the
same
question.
It's
is
the
subject
authorized.
It
just
turns
out
that,
on
the
left,
the
subject
is
the
application
or
technically
the
application
service
principle
and
on
the
right,
it's
the
user.
So,
ultimately,
the
question
is:
is
the
thing
or
person
that's
identified
by
in
this
api
request?
Are
they
authorized
to
take
this
action?
B
That's
the
first
question
now
when
an
application
is
accessing
on
behalf
of
a
user,
it's
the
application
is,
is
not
allowed
to
do
anything
it
wants
on
behalf
of
the
user.
The
application
will
be
restricted
and
limited
or
a
scoped
is
another
term
we
use
to
what
it
can
do
on
behalf
of
the
user.
So
there's
a
second
question
in
terms
of
authorization
which,
with
that
the
api
will
ask,
is
the
app
allowed
to
do
this
on
behalf
of
this
user
right,
and
so
when
it's
access
on
behalf
of
a
user.
B
B
If
you
imagine
a
list
of
everything
that
a
user
is
allowed
to,
do
all
the
actions,
read
files
or
read
this
one
file
list,
all
users
etc,
all
the
actions
user
could
do,
and
then
you
list,
you
have
a
list
of
all
the
things
that
the
application
is
allowed
to
do
on
behalf
of
that
user.
Then
you
intersect
the
two:
that's
what
the
application
will
also
actually
be
able
to
do.
B
The
application
won't
be
able
to
do
something
that
the
user
themselves
is
not
allowed
to
do,
which
is
one
of
the
big
benefits
of
this
form,
because
there's
no
risk
of
the
application
accidentally
allowing
the
user
to
do
something.
The
user
shouldn't
have
been
able
to
do,
and
the
user
won't
be
able
to
use
the
application
to
do
something
that
they
wouldn't
otherwise
be
allowed
to.
B
For
these
two
forms
of
access.
We
have
two
types
of
permissions.
So
when
we're
talking
about
permissions
for
access
on
behalf
of
a
user,
we
have
something
we
call
delegated
permissions,
and
these
delegated
permissions
are
used
for
answering
that
second
question:
it's
for,
representing
what
an
application
is
allowed
to
do.
B
On
behalf
of
a
user,
and
so
when
we
say
an
application,
has
the
delegated
permission,
user.read.all
we're
not
saying
the
application
can
read
all
users,
we're
saying
the
application
can
read
all
users
on
behalf
of
a
user
and
so
whether
or
not
the
application
will
actually
be
able
to
read.
All
users
depends
on
whether
the
signed
in
user
is
allowed
to
read
all
users,
and
so,
if
the
sign
in
user,
for
example,
is
a
guest
user
who's
not
by
default,
allowed
to
read
all
users
that
won't
work.
B
One
form
we
have
for
granting
the
permission
to
access
data
directly
microsoft
graph
is
what
we
call
application
permissions.
We
also
call
them
app
rules.
Apples
is
actually
the
more
general
term.
There
are
two
flavors
of
april
or
actually,
technically
speaking,
there's
one
flavor
of
april
that
can
be
configured
to
be
an
apple
that
can
be
given
to
a
user.
B
We
don't
use
those
for
microsoft
graph,
but
we
can
also
have
apples
that
can
be
granted
to
applications
or
to
application
service
principles
and
the
app
roles
that
can
are
configured
so
that
they
can
be
assigned
to
other
applications.
That's
that's
what
we
call
application
permissions,
but
really
they're,
just
apples,
and
so
every
api
that's
registered
in
the
microsoft
identity
platform,
including
microsoft
graph,
can
define
a
list
of
application,
permissions
or
a
list
of
app
roles,
and
they
can
define
a
list
of
delegated
permissions
and
so
microsoft.
B
As
the
publisher
of
the
microsoft
graph
application,
we've
defined
a
list
of
application
permission,
a
pretty
long
list
and
a
list
of
delegated
permissions.
One
thing
to
keep
in
mind
is
that
it
is
for
especially
for
direct
access
application.
Permissions
are
not
the
only
way
to
authorize
an
application
to
access
data
through
microsoft,
graph
or
through
other
apis,
and
one
good
example
of
an
api
that
doesn't
rely
on
application.
Permissions
for
authorization
for
direct
access
would
be
azure.
B
So,
if
anybody's
familiar
with
the
azure
management
api,
there
are
no
application
permissions
instead
directly
in
azure,
an
application
or
a
service
principle
that
represents
an
application,
can
be
granted
a
role
in
an
azure
subscription
and
can
be
given
access
to
data
directly
like
that.
That
application
is
still
going
to
use
microsoft,
identity
platform
to
get
a
token,
for
example,
to
azure,
but
that
token
won't
identify
any
application.
Permissions
it'll
say:
look,
I
don't
know
what
they
have
access
to,
but
this
is
who
they
are,
and
then
it
is
the
resource.
B
The
api
in
this
example
azure
the
azure
management
api.
That's
going
to
look
and
see.
Okay,
do
they
have
access?
The
same
applies
for
microsoft.
Graph
except
microsoft.
Graph
also
has
application
permissions,
so
it
is
possible
and
in
some
cases,
explicitly
supported
for
applications
to
be
granted
other
forms
of
permission
to
access
data,
for
example
an
application
or,
whenever
I
say,
an
application
in
terms
of
authorization.
I'm
actually
saying
the
service
principle
for
an
application
within
a
customer's
tenant
can
be
made
owner
of
a
group
and
when
a
service
principal
is
owner
of
a
group.
B
B
Likewise,
a
service
principle
can
be
assigned
a
directory
role,
it's
possible
to
take,
let's
say
the
application
administrator
directory
role,
assign
it
to
a
service
principal
and
let's
make
it
even
fancier,
let's
assign
it
to
a
service
principle,
but
scoped
only
to
one
other
service
principle.
So
we've
taken
a
service
principle
representing
your
application
we've,
given
it
the
role,
application
administrator,
but
only
over
one
other
service
principle,
and
so
by
that
point,
that
application
will
be
able
to
get
a
token
call
graph
and
make
use
of
that.
B
So
it's
a
really
important
point
to
call
out
is
that
not
all
forms
of
authorization
are
necessarily
going
to
be
application,
permissions
and
delegated
permissions.
It's
also
possible
for
apps
to
be
authorized
in
other
ways,
but
going
back
to
these
two
forms.
One
thing
that's
particular
about
the
two.
B
These
two
types
of
permissions
application
permissions
and
delegated
permissions-
is
that
they
can
be
requested
and
there's
this
experience
that
we
call
consent
where
the
application
developer,
the
application,
publisher,
requests
permissions
and
then
the
customer
that's
trying
to
use
that
application
has
an
opportunity
to
grant
those
permissions
and
then
microsoft,
identity
platform
is
sitting
in
the
middle,
helping
orchestrate
this
negotiation.
Let's
say
right
so
one
way
in
which
an
application
can
request
permissions
for
microsoft.
B
Graph
is
during
sign
in
right,
so
during
sign
in
using,
of
course,
a
a
library
like
emcell,
an
application
can
dynamically
request
permissions
in
this
case
delegated
permissions.
Now
we
know
it's
delegated
permissions
because
I
said
during
sign
in
so.
If
it's
during
sign
in
it
means
there's
a
user
involved,
and
so
necessarily
we're
talking
about
those
permissions
that
are
on
behalf
of
the
user.
An
applicant
can
dynamically
request
a
list
of
permissions.
In
this
example,
user,
read
and
user
read
basic
call.
Now.
B
B
The
other
way
to
do
this,
it's
also
as
part
of
sign
in,
is
what
we
call
static
consent
requesting
the
whatever
permissions
have
been
configured
so
here,
instead
of
requesting
any
list
of
permissions,
we're
just
saying
dot
default
or
technically,
because
if
omitted,
we
assume
it's
microsoft
graph.
This
would
be
https
graph.microsoft.com.default
and
what
that
means
is
the
application
is
trying
to
get
access
to
microsoft
graph.
But
it's
not
stating
what
permissions.
B
If
these
permissions
are
granted
in
this
case,
this
will
actually
revoke
anything
that
was
granted
previously.
This
does
allow
configuring
both
application,
permissions
and
delegated
permissions.
So
when
it
comes
to
granting
the
permission,
so
we
talked
about
direct
access
access
on
behalf
of
a
user
for
direct
access.
We
have
application
permissions
for
access
on
behalf
of
a
user.
We
have
delegated
permissions.
B
We
talked
about
how,
during
sign
in
or
through
the
configuration
you
can
configure
your
client
application
to
request
permissions
and
when
it
comes
to
granting
permissions,
one
way
to
grant
permissions
is
through
the
consent
experience.
So
when
an
app
requests
access,
the
user,
that's
signing
into
the
app
might
be
prompted
for
consent.
It's
very
important-
and
this
is
an
example
of
a
consent
screen
for
the
microsoft
graph
explorer
application
trying
to
get
access
to
graph
right.
B
In
this
example,
the
user
here
was
allowed
to
consent
to
these
permissions
and
they
actually
have
the
option
to
accept,
but
it's
very
possible
that
a
user
signing
into
an
application
will
actually
not
be
allowed
to.
Every
customer
can
configure
when
users
are
allowed
to
consent
and
which
users
are
allowed
to
consent
for
applications,
and
customers
can
take
into
account
publisher
verification.
So
in
this
example,
here
it
is
a
verified.
The
app
does
come
from
verified
publisher.
They
can
take
into
account.
B
Customers
can
choose
permission,
classifications
and
say:
look
I'll
only
allow
users
to
consent
to
permissions
from
verified
publishers,
and
only
if
they're,
one
of
these
permissions
that
I've
classified
low
and
then
there
are
other
conditions
such
as
where
the
app
was
registered,
maybe
an
individual
trusted,
app
publisher,
etc.
So
there's
lots
of
variables
and
as
an
app
developer,
you
should
never
assume
that
users
will
be
able
to
consent
to
your
application.
B
We
have
this
screen
here,
which
is
the
user,
is,
is
offered
the
opportunity
to
request
access,
and
so
in
this
example,
if
the
app
was
requesting
access
to
all
users
profiles,
which
is
a
permission,
this
user
wasn't
allowed
to
consent
on
their
own.
They
could
fill
out
this
information
request,
access
that
would
go
to
a
queue
people
would
get
notified
and
the
admins
will
then
have
an
opportunity
to
review
that
and
decide
whether
they're
comfortable
with
this
access
to
their
organization's
data
or
not.
B
Now,
consent
is
one
way
and
what
we
actually
walk
through
here
is
what
we
call
user
consent
where
a
user's
consenting
for
delegated
permissions
on
behalf
of
themselves.
There
are
a
few
other
flavors
or
forms
of
granting
these
two
permissions
that
we've
talked
about
the
first
one
is
admin,
consent
or
tenant-wide
admin
consent,
as
the
name
suggests.
This
is
something
that
is
a
very
privileged
operation
that
normally
an
administrator
would
do
by
default,
global
administrator.
B
In
some
cases,
application
administrator
can
do
right.
This
is
for
granting
tenant-wide
consent.
So
we're
not
saying
this
application.
You
can
do
these
permissions
on
behalf
of
this
one
user,
we're
actually
saying
on
behalf
of
all
users,
so
any
other
user
in
the
organization
who
signs
into
that
same
application.
B
Admin
consent
can
be
triggered
by
the
application
by
redirecting
the
user
off
to
a
special
url.
They
can
be
done
from
the
azure
portal
from
the
the
admin
consent,
request,
queue
or
just
from
under
the
apps
listed
in
enterprise
apps
and
some
customers
have
taken
to
constructing
the
admin
consent
url
themselves.
There's
lots
of
forms
of
this.
This
works
for
both
there's
a
flavor
for
dynamic
and
for
static.
In
this
example.
B
Here
we've
an
example
of
admin
consent
using
the
static
approach
where
it's
just
for
whatever
is
configured
then,
in
addition
to
that,
customers
can
use
microsoft
graph
to
grant
permissions
so
application
permissions,
as
I
mentioned,
are
actually
app
roles
and
so
to
grant
an
application
permission.
You
create
an
app
role
assignment
delegated
permissions
in
microsoft.
Graph
are
represented
as
something
we
call
oauth
2
permissions
or
oauth
to
permission
scopes
and
to
grant
them.
B
What
you
create
is
an
oauth
2
permission
grant
and
an
app
role
is
very
simple:
it
identifies
the
api,
it
identifies
the
client
app
service
principle
and
identifies
which
app
role
so,
which
application
permission
and
delegated
permission
is
basically
the
same.
There's
the
client
application,
the
api,
the
permission
or
actually
the
list
of
delegated
permissions
there's
an
extra
thing
which
is
on
behalf
of
whom,
on
behalf
of
one
user
or
on
behalf
of
all
users,
so
both
of
those
can
be
done
with
microsoft.
B
B
Almost
every
application
permission
is
what
we
call
tenant
wide
right
all
files
in
the
entire
organization,
the
files.read.all
permission,
delegated
permissions
are
restricted
to
what
the
user
can
access,
but
within
the
scope
of
what
the
user
can
access.
It's
any
file
in
the
organization
that
the
signed
in
user
can
access.
Many
users
can
access
a
lot
of
files
and
some
of
them
might
be
quite
sensitive,
and
it
might
be
that
the
application
really
only
needs
access
to
some
of
them.
B
Other
permissions
do
actually
limit
which
resources
can
be
accessed
so,
for
example,
the
user.read
permission
only
allows
reading
one
user
profile
and
that's
the
user
profile
of
the
signed
in
user.
Mail.Read
likewise
only
allows
accessing
one
mailbox,
which
is
the
mailbox
for
the
signed
in
user.
So
these
are
examples
of
delegated
permissions
that
do
restrict
the
set
of
resources,
but
it's
important
to
keep
in
mind
that
that's
why
many
of
the
other
permissions
end
in
all,
because
it's
for
a
lot
of
things
now.
B
Even
delegated
permissions,
though,
can
also
be
very
broad
or
very
sensitive,
for
example,
and
what
ends
up
becoming
most
important
there
is
who
is
signing
in
if
an
administrator
signs
in
and
an
application
has
been
granted
the
delegated
permission
to
take
administrative
actions,
and
if
you
have
an
admin.
Well,
you
can
do
anything.
You
want
basically,
at
that
point,
if
the
ceo
of
the
company
or
some
other
user,
with
access
to
highly
sensitive
data
signs
in
the
application
might
have
access
to
that
data.
B
So
that's
something
to
keep
in
mind
and
a
very
good
reason
to
make
sure
you're
only
asking
for
access
your
application
really
needs.
There
are
some
capabilities
available
today
and
more
coming
soon
to
restrict
the
set
of
resources
that
an
app
can
access
so
for
mail,
calendar
and
contacts,
so
things
in
exchange
online.
We
have
something
today
called
exchange
app
access
policies
that
can
allow
limiting
the
set
of
mailboxes.
The
app
has
access
to
a
set
of
calendars,
a
set
of
user,
mailboxes,
etc.
B
There
is
a
limit
today
in
the
number
of
policies
that
can
be
created
in
one
tenant
in
one
organization.
So
that's
one
of
the
limitations
today,
as
I
mentioned,
we're
working
on
some
changes
in
this
area,
coming
up
teams,
channels
and
conversations,
and
what
we're
working
on
is
in
general
for
for
ways
to
to
restrict
access
for
teams,
channels
and
conversations
a
team
owner.
So
this
is
in
microsoft.
Teams
a
team
owner
can
consent
when
installing
a
team's
app
to
only
give
the
app
access
to
that
team.
B
We
can
restrict
that
to
just
the
data
for
a
specific
team
and
it's
the
team
in
which
the
app
was
installed
for
sites.
We
have
a
new
capability,
sharepoint
site
collections,
there's
a
new
capability
that
allows
an
admin
to
consent
to
sites.selected,
which
is
a
restriction
basically
saying
hey.
This
app
has
access
to
specific
individual
sites
and
then
on
sharepoint
using
microsoft.
Graph
can
say:
okay.
B
Looking
at
time,
I'm
going
to
wrap
up
there,
a
few
reminders
is,
as
an
app
developer,
always
ask
release
privilege
permissions,
keep
an
eye
on
the
graph
api
and
once
in
a
while,
just
check
in
to
see
if
there's
any
new
permissions,
especially
if
some
permission
in
particular
is
causing
you
heartache,
because
you
have
to
ask
for
difficulty
for
your
customer
customers
to
actually
grant
access,
because
it's
more
privileged
than
you
actually
need
to
you.
Just
don't
have
any
other
option.
B
We're
constantly
working
on
defining
new
permissions
that
are
lesser
privileged
to
allow
more
granularity
there
and
as
an
app
customer,
do
keep
in
mind.
If
you
see
an
application,
that's
asking
for
more
than
you
think
it
needs
dig
into
that,
find
out
why
and
and
often
challenging
the
application,
publisher
or
developer.
The
result
is
oh
yeah.
B
I
was
actually
just
testing
and
I
finally
found
a
combination
that
worked
and
I
stopped
there
and
maybe
there's
something
better
than
that
and
on
our
side,
we're
working
at
microsoft,
we're
working
on
some
ways
to
better
inform
developers
and
customers
on
what
the
best
combination
is
for
the
scenarios
always
prefer
delegated
access,
so
access
on
behalf
of
a
user
over
direct
access.
If
there's
a
user
involved
right.
So
if
there's
a
user
involved,
you
don't
want
your
application,
which
has
been
granted
more
access
than
the
user.
B
To
be
the
reason
the
user
was
exposed
to
data
they
weren't
supposed
to
see
and
delegated
access
not
only
restricts
the
scope
of
access
of
your
application,
which
is
a
good
thing.
It
makes
sure
that
the
rules
that
are
enforced
include
the
authorization
for
whatever
whoever
signed
it.
Then,
whenever
you
can,
if
you're
doing
a
teams
app
if
you're
accessing
sharepoint
always
use
these
options
to
have
lesser
privilege
and
smaller
scopes
of
access
wherever
possible,
and
you
can
expect
that
moving
forward,
there
will
be
more
opportunities
for
this
all
right
in
one
minute.
B
B
Generally
speaking,
a
role
or
authorization
in
general
will
not
be
given
to
an
app
registration.
It
will
be
given
to
the
service
principal.
I
only
make
that
distinction,
because
if
you
ever
try
to
do
it
through
graph
or
something
you
won't
want
to
assign
a
role
to
the
application
entity,
you
want
to
assign
it
to
the
service
principal
entity
that
maps
to
that
application.
So
technically
it
is
possible
to
take
any
directory
role
and
assign
it
to
any
service
principle,
but
that
doesn't
necessarily
mean
that
the
result
will
be
what
you
expected.
B
Ideally
it
would,
but
today
there
are
some
directory
roles
that
don't
work
or
are
not
recognized
in
some
areas
of
microsoft,
graph
and
microsoft
365
in
general
directionally.
We
want
all
of
these
roles
to
work
for
all
of
them,
so
it
is
possible
to
take
the
teams
communication
support
specialist,
to
sign
it
to
a
service
principal
so
that
application
can
then
use
the
direct
access.
Flavor
get
an
app
only
access
token.
The
question
then,
is:
will
this
work
and
do
what
you're
expected
to
do
and
to
answer
that
question?
B
A
Excellent,
thank
you
so
much.
That
was
a
excellent
overview
of
at
this
time
really
getting
some
of
the
the
nice
details.
I'm
sure
a
lot
of
people
are
having
questions
about,
so
thank
you
so
much
for
that.
Yes,
see.
A
lot
of
applause
is
now
in
the
thanks
for
the
bottom
motion,
so
excellent.
Thank
you
so
much
again
for
your
time
and
really
appreciate
it.
C
So
everyone
thank
you,
for
you
know,
jumping
on
the
call
today
and
in
fact,
a
lot
of
what
philippe
mentioned
today
actually
plays
well
into
into
the
conversations
that
we're
planning
to
have.
One
of
the
reasons
why
I
wanted
to
have
this
conversation
with
you
all
is
because
here
at
microsoft,
we,
you
know,
hear
from
a
lot
of
partners
and
customers.
C
C
If
you
are
creating,
you
know,
such
an
object
is
to
get
instant
visibility
into
your
microsoft
outlook
calendar.
So
if
this
is
important
to
you,
where
you
want
to
ensure
that
that
online
meeting
that
you're
creating
is
visible
inside
that
person's
outlook
calendar,
you
know
you
get
that
the
ability
to
update
and
manage
the
online
meeting
experience
in
outlook
is
another.
One.
C
You'll
see
me
talk
about
this
a
little
bit
later,
when
we
talk
about
the
meeting
lobby
and
attendees
may
join
in
person
or
online
or
over
the
internet
or
very
darling,
so
there's
different
modalities
of
how
a
person
can
join.
You
know
this
meeting
and
obviously,
if
you
have
rich,
you
know
the
rich
client
features
if
you're
inside
microsoft
teams
or
if
it's
a
microsoft,
microsoft
outlook.
These
are
areas
where
you
know
where
you
can
get.
You
know
the
full
enrich.
C
You
know
feature
so,
if
you're
looking
at
this
in
terms
of
what
this
can
be
done
or
you,
the
app
developer,
are
creating
this
from
the
api.
There's
a
couple
other
things
that
you
actually
get
as
well,
too
you're
able
to
inspect.
You
know
using
the
allowed
online
meeting
provider
property
to
see
what
type
of
meetings
that
you
can
create,
and
you
are
also
let's
say
that
you're
you're
you're
targeting
you
know
the
api
endpoint,
slash
events
and
you're
looking
at
them
to
see.
What's
there.
C
If
you
look
at
the
is
online
meeting,
you
can
visually
inspect
that
to
see
if
it
is
an
online
meeting
or
not
and
thereby
convert
something
that
was
not
an
online
meeting
to
an
online
meeting.
You
basically
see
that
at
the
bottom
right
in
terms
of
that
screenshot
being
called
out,
you
know
slash
events,
slash
the
event
id
and
then
set
in
that
flag
from
what
was
previously
false
to
true
and
then
also
creating
an
online
meeting
provider.
So
you
know
that's
one
approach
there.
C
You
know
to
go
into
what
philippe
mentioned
before,
there's
a
permission
model
set
for
this
and
yeah.
This
one
is
pretty
simple:
it
is
basically
calendar.read
write
for
both
delegated
and
application
permission.
So
you
know
one
set
of
permissions,
that's
required
and
it
flows
better
or
not
you're
doing
direct
access
as
philip.
You
know
you
know
termed
it
or,
if
you're,
using
delegated,
where
you
require
that
users
consent.
So
pretty
easy.
C
If
you
wanted
to
do
this,
for
instance,
if
you
had
you
know
something
inside
a
you
know,
google
account
or
if
it's
inside
another
application
like
a
service
now
or
something
else,
and
you
wanted
to
basically
have
an
online
meeting,
then
you
know
this
is
something
that
is
given
is
given
and
granted
to
you.
So
basically,
it
is
completely
decoupled
from
outlook
calendar.
You
know,
so
it
doesn't
does
not
create
one
an
event
for
you.
C
C
This
one
does
require
that
you
have
the
licenses
for
it
as
well.
You
see
me
call
it
out
a
little
bit
later
on
and
you're
able
to
really
manage
attendance
at
the
granular
level.
In
terms
of
you
know,
one
of
the
ones
being
you
know
whether
this
attendee
you
know
can
can
bypass
the
lobby
and
other
amnio
security.
You
know
security
enablement
that
you
can
do
around
the
user.
So
really
you
know
you
can
really.
C
C
You
can
see
here
that
you
know
for
the
delegated
permission,
you
need
online
meetings,
dot
read
write,
but
for
the
application
permission
it's
online
meeting
read
write
at
all
with
a
little
asterisk
they're
saying
that
you
know
the
administrator
would
need
to
basically
create
and
that
policy
for
your
app
in
order
to
run
and
run
in
that
modality.
So
if
you're,
using
app
permission
other
than
delegated
permission,
there's
additional
steps
that
are
required.
C
So
you
know,
as
I
was
putting
together
this
this
deck
and
because,
as
I
mentioned
before,
this
is
something
that
you
know
the
team
here.
You
know
the
customer
partner
experiences
team
that
I'm
a
part
of
here
all
the
time.
These
are
questions
that
I
get
or
questions
that
I
would
sometimes
post
back,
and
I
think
I
still
mentioned
you
got
to
interrogate
people.
That's
asking.
Why
do
you
need
this,
or
why
does
you
have
to
need
that?
C
So
I
typically
would
ask
these
questions
and
I
encourage
you
to
ask
yourself
these
questions
in
order
to
get
the
answer.
So
if
one
of
you
want
to
call
here
come
back
to
me
later
on,
I
I
will
purposefully
pull
this
slide
up,
but
you
know
quite
quite
simply,
if
you
know
if
you
need
to
integrate-
and
I
think
if
you
some
of
these
are
like,
if
I
were
to
quiz
you
at
the
end-
you've
already
gotten
some
of
the
information
before.
C
But
if
you
need
to
integrate
with
a
calendar
item,
I
think
it's
pretty
clear.
We
talked
about
that
before.
If
you
need
to
go
into
microsoft
outlook,
what
api
would
be
using
so
read
all
of
the
stuff
and
look
at
the
very
bottom.
You
can
see
clearly
see
it's
the
calendar
api
in
order
to
do
that,
because
the
cloud
api
is
fully
decoupled,
so
pretty
self-explanatory.
C
I
don't
think
there's
anything
else
here
that
I
wanted
to
touch
on.
I
know
you're
reading
the
slide,
as
I'm
going
one
of
the
things
to
call
out.
I
didn't
want
to
create
a
visual
aid
for
you,
the
fact
that
it
is
tied
directly
to
outlook
this
is
exactly
what
that
experience
would
be.
So
if
you're
in
outlook
or
oah,
and
you
click
on
the
item.
This
is
what
you're
going
to
see
coming
up
a
little
bit
of
a
call
out
here.
C
The
answer
is
notable
another
one
is
if
you
need
language
based-
and
I
think
I
touched
on
this
before-
do
you
need
to
manage
language
based
information,
then
the
answer
is
no,
if
you're
using
a
calendar
api
but
as
I
mentioned
before,
because
the
cloud
communications
api
is,
you
know
very
nuanced-
it's
very,
very
granular
you're
able
to
do
that
and
you'd
manage
that
experience
by
actually
modifying
one
of
the
optional
http
headers.
In
order
to
be
able
to
set.
C
You
know
it's
either
ian
for
english,
esp
espanol,
fr,
french
and
so
on
and
so
forth.
If
you
are-
and
this
is
the
other
one
now
a
little
bit
it's
unhidden,
but
if
do
you
need
to
join
by
internet
voice
over
ip
or
by
dial
up
that's
what
the
question
has
been
asked
right
here,
and
you
know
the
answer
is
yes
to
both
on
this
one
right.
So,
whether
or
not
you're
using
the
calendar
api
or
the
cloud
com
communications,
api,
you're
able
to
join.
C
C
The
next
one
is:
do
you
need
to
create
an
online
meeting
that
refers
to
a
chat?
I
think
so
it's
pretty
much
self-explanatory.
We're
talking,
chat,
we're
talking,
teams
right,
we're
talking!
You
know,
groups
we're,
definitely
not
talking
calendar
and
events.
So
for
this
one
under
the
calendar
api,
it
is
not
supported.
However,
if
you
are
doing
this
inside
on
the
cloud
comms
as
long
as
you
have
the
chat
id,
you
can
basically
create
a
meeting
surrounding
the
chat.
C
So
it
has
some
context
in
terms
of
what
you're
going
to
be
discussing
this
one
where
you
need
to
manage
a
meeting
inside
the
lobby
and
that's
the
reason
why
I
mentioned
before
that
this
one's
a
little
bit
tricky.
It
is
unsupported
in
the
events
api.
However,
if
you
were
to
create
online
meeting
using
the
calendar
events
api,
it
would
have
a
link
inside
microsoft
outlook
for
meeting
options,
and
if
you
click
on
that
link
for
meeting
options,
you
will
be
able
to
have
effect
changes
there.
If
you
are
using
the
cloud
comp
api.
C
I
think
I
mentioned
before
also
in
the
larger
narrative,
where
I
said
that
you
know
you
have
very
granular
control
over
the
end
user
experiences.
You
know
you
so
basically
it
is
a
property
that
you
can
affect,
and
you
can.
You
can
really
be
really
granular
and
nuanced
with
that,
if
you
were
to
click
the
meeting
lobby,
link
inside
microsoft,
outlook,
for
instance,
this
is
the
visual
that
you
basically
would
get.
You
know
these
are
some
of
the
options
that
are
available
to
you.
C
Okay,
so
I
believe
I'm
coming
up
on
the
last
slide
right
now.
This
is
basically
just
some
resources
for
you
a
lot
of
what
I
say
right
here
again.
The
reason
for
this
is
because,
depending
on
what
you're
searching
for,
especially
if
you
don't
know
what
you're
searching
for,
sometimes
it
can
be
difficult
to
find
it
even
sometimes,
if
you
know
what
you're
searching
for,
because
you
may
find
it
in
in
essence,
two
different
locations,
but
if
you're
trying
to
create
an
online
meeting,
you
may
find
it
in
canada.
C
You
may
find
in
events,
there's
actually
a
good
blog
about
choosing
the
api
one
which
you
actually
took
a
lot
of
this
content
from,
but
I
formatted
it
here
in
in
a
more
simpler
ask
in
a
questions
format.
Some
of
these
guidance
is
going
to
be
here
and
again.
You'll
get
this
link
in
my
deck
afterwards,
but
as
you're
doing
all
of
these
items
as
well.
One
of
the
things
that
I
hear
from
our
partners
and
customers
also
is
around.
C
You
know:
hey
we're
we're
creating
an
app
to
do
x,
y
and
z,
and
you
know
we're
we're
trying
to
spin
up
an
online
meeting,
and
you
know
it's
going
to
be.
You
know
thousands,
potentially
thousands
of
people
in
in
attendees
or
hundreds
of
people
and
attendees
and
we're
doing
this
and
we're
having
some
issues
understand
as
well,
that
you
know
the
throttling
guidance
does
apply
here
as
well,
so
be
mindful
of
the
terms
of
use
be
mindful
of
the
endpoints
and
the
throttling.
D
C
And
understand
that
throttling
comes
in
several
different
flavors
as
well
too,
when
you're
working
with
a
microsoft
graph,
your
first
api
stop
is
basically
the
graph
and
the
graph
itself
has
guidances.
It
has
a
lot
of
things
for
you.
It
helps
you
with
for,
if
you're
using
the
sdk
for
one
thing
it
helps
you
with
your
429s,
which
is
your
throttling,
so
you
know
I
encourage
the
use
of
the
sdk
for
that
purposes,
but
if
you're
rolling
it
on
your
own
as
well
and
you're,
hammering
the
api,
you
could
get
some
429.
C
So
you
need
to
handle
that
by
the
guidance
that
are
here.
However,
you
know
there
is,
if
you
do
a
endpoint,
and
you
do
a
question
mark
what,
if
and
behind
it
it
will
actually
show
you
the
back-end
api
that
we
are
also
going
against
as
well
too,
if
you
wanted
to
get
a
little
bit
more
understanding
of
that.
But
I
say
that
to
say
this:
we
are
also
calling
the
back-end
services
and
the
back-end
services
may
also
have
limits
as
well
too.
C
So
I
think,
just
as
philippe
mentioned
before,
there
is
a
there's,
an
intersection
that
could
happen
around
what
we
have
in
terms
of
our
trotline
guidance,
but
also
the
backend
services
as
well
as
it
relates
to
microsoft
graph,
because
these
have
independent
limits.
I
also
call
that
out
here,
there's
exchange
online
limits
that
are
here
and
also
the
cloud
complement
that
are
here
as
well
too.
So
I
think
that's
all
I
had
for
you
exactly
so
open
it
up
for
any
questions
that
you
may
have
ryan.
I
can
give
you
back
for
14
minutes.
A
So
we
got
a
few
minutes
at
the
end
for
just
open
q,
a
and
then
wrap
up,
slides
but
yep
all
right,
but
we'll
wait
for
anyone
to
put
anything
into
the
chat
window
or
feel
free
to
use
the
raised
hand
feature
in
teams.
Thank
you,
fabian
the
great
content.
Here
we
do
get
a
lot
of
questions
on
which
api
should
I
use,
or
what
are
different
scenarios
so
great
to
cover
this
in
a
more
broad
detail.
C
C
Allow
me
to
learn
from
you
as
well.
We
have
a
bunch
of
people
on
this
call.
I'd
love
to
hear
your
story.
Anyone
would
like
to
share.
Is
this
brand
spanking
new,
no
one's
ever
created?
No,
no.
I
made
it.
Okay,
gabrielle
is
using
face
a
couple
of
problems.
Hopefully
gabrielle.
We
cleared
up
some
of
those
problems
here
today
lane
you
have
a
question.
E
Yes,
yeah,
I'm
I'm
looking
to
do
a
a
map
with
resources,
exchanges,
exchange
resources
which
would
be
meeting
rooms.
How
could
I
do
that
with
graph?
I
know
how
to
access
my
own
calendar,
but
does
it
mean
the
exchange
meeting
room
has
to
get
a
email
address
to
make
it
work?
Maybe
because
resources
doesn't
seem
to
be
available
on
on
graph.
A
A
If
you
have,
as
you
mentioned,
like
the
email
address
for
the
meeting
room,
you
can
go
through
the
calendars
api
and
be
able
to
go
and
see
things
like
scheduling
or
calendar
view
or
some
types
of
things,
so
some
of
it
will
depend
on
what
specifically
you're
doing,
if
it's
just
simply
to
add
the
room
as
an
attendee.
You
know
a
resource
to
a
meeting.
There
are
apis
to
go
and
do
that
so
that,
when
you
do
your
sunday
invite
out
basically
create
the
event.
A
A
F
Yeah
so
there's
a
there's,
an
actual
api
that
allows
you
to
get
the
busy
free
schedule
from
a
resource
not
just
from
a
user
but
also
from
an
actual
resource
that
you're
gonna
get
from
the
places
api.
So
that
way
you
can.
You
can
actually
put
that
logic
into
your
app
and
you're
gonna.
Be
able
to
do
that.
Okay,.
A
I
will
check
all
this.
Thank
you
yes
and
then
one
other
thing
just
to
share
the
one
that
seb
mentioned
is
the
free
busy
api,
there's
also
a
find
meeting
times
api
and
there's
a
slight
difference
between
what
gets
returned
for
each
one.
So
one
is,
you
know,
give
me
a
set
of
just
like
available
options.
The
other
one
is,
you
know,
find
the
open
times,
and
then
you
can
kind
of
work
out
which
one
that
you
want
to
schedule
for
so,
and
we've
actually
got
a
separate
document.
A
E
A
B
Let's
say
so
to
keep
things
simple,
the
the
short
answer
is
probably
not
right.
That
is
not
to
say
that
we
don't
want
to
offer
more
options
and
equivalent
query
capabilities
through
graph
and
in
some
cases
it
certainly
will
make
sense
to
offer
options,
either
options
to
put
it
into
gusto
or
something
you
can
query
with
cousteau,
not
acousto
itself
or
azure
data
explorer.
But
I
think
we
will
first
make
sure
that
we
understand
what
limitations
you
have
in
terms
of
querying
and
then
make
sure
that
you're
able
to
query
them
through
graphs.
D
D
B
Almost
everything
that's
in
the
directory,
including,
for
example,
a
list
of
devices,
as
I'm
sure
you
know,
almost
everything,
has
very
limited
string,
search
capabilities
and
that
just
has
to
do
with
the
how
it
was
originally
built
and
is
currently
still
stored
in
under
the
covers.
So
since
then,
we've
actually
added
some
capabilities,
I'm
sure
you're
familiar
with
them
that
allow
full
text
search
for
some
object
types
so,
for
example,
application
and
I
think
service
principle
and
some
end
users.
B
That's
the
problem
right
and
so
what
you
so
so
for
some
things
you
will
see
those
coming
up,
but
what's
most
important
here,
is
that
we
know
what
are
the
ones
that
you're
trying
to
do,
which
ones
you
would
expect
and
or
want
to
be
able
to
do
so.
We
can
make
sure
that
feedback
is
is
communicated
to,
for
example,
the
intune
folks,
if
it
turns
out
to
be
an
intune
api.
G
Just
a
really
quick
thing,
since
you
guys
are
on
that
within
that
same
vein,
I
guess
what
would
be
helpful
to
me,
too,
is
understanding
what
filter
parameters
are
actually
accepted
for
any
given
endpoint,
because
sometimes
it's
hard
to
tell
like
sometimes
the
messages
that
come
back
will,
let
you
know
other
times
my
experience,
that
isn't
always
the
case.
So
it's
like
it's
kind
of
annoying
and
sometimes
what's
supported,
they're
pleasing
to
a
design
right
like
if
filtering.
D
G
B
That's
that
is
something
that
we've
heard
a
few
times
before
and
and
we
have
some
at
least
what
I've
seen
and
other
folks
may
have
some
additional
details,
but
I've
seen
a
few
examples
of
different
choices.
We
have
right
we're
going
through
we're
choosing
between
for
how
just
to
express
this
in
the
documentation
right
today,
in
theory,
internally,
at
microsoft,
everyone
who
owns
an
api
will
go
and
make
sure
hey.
This
property
supports
these
filters,
but
there
are
a
few
problems
with
that.
B
First
of
all,
it's
unstructured,
so
we
can't
easily
take
that
and,
for
example,
make
sure
it's
easily
included
as
part
of
our
auto-generated
documentation
or
taken
into
account
as
part
of
the
sdks
it's
or
things
like
graph
explorer.
That
will
help
you
identify
this.
The
second
problem
is,
we
would
rely
on
humans
to
be
updating
that
and
that
to
be
accurate,
which
is
not
always
the
best
approach.
B
So
one
of
the
things
we're
working
on
is
taking
it
actually
even
earlier
and
making
it
part
of
the
api
description,
so
dollar
metadata
using
that
to
feed
the
documentation.
So
you
can
just
you'll
have
a
table
for
every
api.
It
says
for
this
property.
These
filters
are
supported.
These
ones
are
not,
and
hopefully
that
will
solve
the
discovery
problem.
How
do
I
learn
which
ones
work
which
ones
don't
work
or
which
ones
are
expected
to
work
and
which
one's?
Not
the
other
problem
we'll
still
have?
B
There,
though,
is
there'll,
be
lots
which
are
not
supported,
that
you
might
want
supported,
and
so
for
there
we
really
rely
on
your
feedback
so
that
we
know
which
ones
to
prioritize
so
long
story
short.
You
should
expect
in
the
coming,
let's
say
weeks,
but
maybe
months,
a
much
better
experience
for
learning
which
filters
work,
which
ones
don't
and
please
let
us
know
when
there
are
certain
which
filters
you
would
have
wanted
to
use,
but
did
not
find
available.
A
Excellent,
thank
you
for
sharing
athlete,
good
good
information,
and
if
everyone
is
interested,
we
do
have
a
location
where
you
can
submit
things
like
feature
requests
suggestions,
other
things
related
to
microsoft,
365
or
microsoft.
Graph,
specifically,
aka.ms
m565,
dev
hyphen
suggestions
feel
free
to
fill
out
things
there
or
upvote
additional
ones
that
are
already
out
there.
And
then
we
have
one
minute
left
I'll.
Just
go
quickly
through
the
last
slides
on
here.
Quick
call
out
if
you're
interested
in
joining
the
microsoft
graph
tap
is
our
technology
adoption
preview
program.
A
We
offer
a
monthly
call
with
this,
so
as
well
as
some
additional
benefits
for
this
feel
free
to
submit
the
form
at
aka
dot.
Ms
slash
graph
tap
form.
We
also
have
a
number
of
different
microsoft.
365
developer
community
calls
ourselves
depth
of
cards,
identity
teams,
office,
add-ins
power,
apps,
sharepoint
and
more
feel
free
to
take
a
look
at
the
link
at
the
very,
very
bottom
aka
dot.
A
Ms
slash
m365
dev
calls
you
can
get
a
listing
of
all
the
different
calls
out
there,
as
well
as
links
to
go
and
join
with
those
I'll
call
out
to
our
mike's
a365
developer,
podcast,
run
by
jeremy,
thicke
and
paul
shapeline
great
way
to
keep
up
to
date
on
what
is
happening
in
the
mexico.
365
developer,
ecosystem
news
announcements,
other
types
of
solutions
that
are
being
shared
out
also
the
microsoft
graph
meal
bag.
This
is
a
bi-monthly
posting
where
we
share
our
different
kind
of
lessons
learned
different
samples
of
things
related
to
microsoft.
A
Graph,
you
can
find
this
at
aka
dot,
ms
ms
craft
mailbag
and
a
big
thank
you
to
everyone
for
joining
in
today.
Sharing
any
of
your
questions,
your
applause,
your
feedback,
all
very,
very
welcome.
You
can
find
the
recording
for
today's
session,
we'll
be
out
on
the
microsoft
65
developer,
youtube
channel
that'll
be
posted
once
it
is
available,
and
a
note
for
our
next
call
will
be
on
june
1st
at
8
a.m.
Pacific
time
as
well,
you
can
find
the
link
for
joining
in
aka.
Ms
slash
soft
graph
call
so
big.