Microsoft Graph Feature Requests

Welcome to the Microsoft Graph UserVoice! Do you have anidea or feature suggestion based on your experience with Microsoft Graph?Please share these with us by submitting your idea below or voting up ideassubmitted by other users. This forum will be directly monitored by theMicrosoft Graph engineering teams who are working on new features every day.

If you have feedback on a specific API service, pleasechoose the corresponding category. Please submit any broad ideas related toMicrosoft Graph or ideas across more than one service to the “General”category.

This site is only for feature suggestions and ideas! If youneed technical help, please go to the Microsoft Graph StackOverflow or if you have a Premier support contract raise a support ticket.

For more information on the Microsoft Graph, please checkout https://graph.microsoft.com .


  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Graph - Modify the Expand Method to allow TOP and Paging

    I would like to suggest allowing a TOP on the Expand method and implementing paging. Currently only the first 20 records are being returned and there is no way to get more records. 20 seems arbitrary, and well useless at this point. The reason is that a good number of calls might get away with one call to the Graph server vs several, unless of course separate calls are being made under the covers anyway. I would liken this to doing an Include in the Entity Framework Core world whereby I could pull thousands of records for a child table…

    2 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →

    Agree that this half-way house support is a bit ridiculous. We would have been better off failing the request as not supported, than have this return 20 max items behavior.

    Anyway, we’ll be looking at how we can enable paging support on expanded collections, but in the meantime this type of operation may first return a 400 in the future (conscious that this is a breaking change).

    Hope this helps,

  2. Increase webhook subscription from 3 days to about 6 months

    From the developer's view, ideally the webhook subscription will never expire. But that's probably not practical.

    The next best would be say 6month expiry. Because that means we still need to build a re-scheduling mechanism. But we don't have to run it every 3 days.

    I believe if the expiry was too long say 1 or 2 years, the developers will leave without building a re-scheduler, so the webhook will just break in 1 year's time.

    Currently, because the webhook subscription expires every three days, we are driving a behaviour where developers don't use webhooks - they just use scheduled…

    9 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →

    We are working on extending the webhooks framework with new functionality, and this will also allow us to increase subscription lifetime. -EY

  • Don't see your idea?

Feedback and Knowledge Base