Yes — Microsoft Graph can tell you exactly who reports to you, straight from Entra ID (Azure AD), via GET /me/directReports. Nothing in Microsoft Planner uses that data. Every native Planner view organizes tasks by plan, not by reporting line, so “show me my team’s tasks” means picking each report’s name by hand, one plan at a time. And the API itself has a hard ceiling worth knowing before you build on it: it returns only the people who report straight to you, one level down — not their reports, not the wider org chart underneath them. Here’s what the endpoint actually gives you, exactly where it stops, and how to turn it into a real manager view.

Does Microsoft have an API for my direct reports?

Yes, and it’s not new or obscure. GET /me/directReports (or GET /users/{id}/directReports for someone other than yourself, with the right permission) is a standard Microsoft Graph v1.0 endpoint that “get[s] a user’s direct reports,” returning “the users and contacts for whom this user is assigned as manager” (Microsoft Graph). It reads straight from the manager field Entra ID already tracks for every account — the same field HR systems sync into Azure AD when someone joins a team. If your org has ever set “reports to” on a user profile, this endpoint already knows your reporting line. Nobody has to build an org chart; it exists.

For a delegated call against your own reports, the least-privileged permissions are User.Read and User.ReadBasic.All — a normal signed-in-user scope, not an admin-only grant (Microsoft Graph).

So why doesn’t any Planner tool use it?

Because Planner’s entire data model is built around the plan, not the person, and every native Planner surface inherits that boundary. The Charts view breaks a single plan down by status, priority, bucket, and member — but it has no idea who reports to whom (Microsoft Support). Portfolios roll up milestones and status across many plans, filterable by fields like assignee — but again, no manager relationship in sight (Microsoft Support). “Assigned to me” only ever shows your own tasks. None of Planner’s views were built to ask Entra ID “who works for this person” and then go find their tasks — even though that answer is one Graph call away.

This isn’t a hypothetical gap. It’s been an open request on Microsoft’s own Community Hub since 2017: a thread titled “Planner Dashboards (Cross Planners, AD Direct Reports, Etc.)” asks exactly for a rollup “for project managers/admins” organized around Active Directory’s manager hierarchy — and it’s still open, with people replying that the AD-manager angle still isn’t native (Microsoft Community Hub). The plainer version of the same ask — a manager wanting to see what one report has on their plate across every project — has been asked separately too, in a thread that’s racked up on the order of 30,000 views: “Way to see all Planner tasks assigned to a team member?” (Microsoft Community Hub). Different phrasing, same wall: Planner can’t answer “what does my team have on its plate” without a manager going report-by-report and plan-by-plan.

What does directReports actually return?

A flat list of the people (and, occasionally, contacts) whose manager field in Entra ID points at you — id, display name, mail, job title, and the rest of the standard user fields Graph exposes, filtered by whatever access the caller has (Microsoft Graph). That’s it: a name list, not tasks. To turn it into “what my team is working on” you still have to take each id from that list and separately pull their Planner tasks — the directReports call gets you the who, not the what.

The honesty limit: this is one level, not an org chart

This is the part worth being exact about, because it’s easy to overclaim. Microsoft’s own documentation for the endpoint says it directly: “This API doesn’t support getting the direct report chain beyond the specified user’s direct reports.” (Microsoft Graph)

In plain terms: /me/directReports gives you the people who report straight to you — one level down. If one of those people is themselves a manager with their own reports, this call does not hand you that second layer. You’d have to call directReports again for each of your reports individually, and again for theirs, walking the chain yourself, one level at a time, with no built-in “give me the whole subtree” option. For a manager with, say, five people reporting directly to them, that’s exactly the group this page is about. For a VP who wants their entire department rolled up three or four layers deep, directReports alone won’t get you there — that’s a different, heavier build (recursive Graph calls per layer, with the pagination and rate-limit handling that implies), not a one-call feature.

So: real capability, real limitation. It answers “what’s on my direct team’s plate,” not “what’s on my whole org’s plate.”

How would I actually build the manager view?

The shape, if you’re doing it yourself:

  1. Register an app in Entra ID and request User.Read + User.ReadBasic.All (delegated) so a signed-in manager can read their own directReports.
  2. Call GET /me/directReports to get the list of people who report to the signed-in manager.
  3. For each report, call the Planner tasks endpoint — the same GET /users/{id}/planner/tasks route used for any cross-plan, per-assignee view — to pull their tasks across every plan they belong to.
  4. Join and page — resolve planId to plan names, follow @odata.nextLink, and render one list per report or a combined team view.

Nothing here is exotic; it’s the same Graph plumbing behind every other cross-plan Planner report. The only new piece is step 2 — asking Entra ID who’s on your team instead of typing names in by hand.

The honest funnel

That’s the exact pipeline we built into Team Workload for MS Planner. Its People presets call GET /me/directReports for you, then pull each report’s Planner tasks across every plan you can access — grouped, due-date sorted, on one screen. No app registration, no manual name-picking, no Power BI model. It’s scoped honestly the same way the API is: your direct reports, one level down — not a full org-chart rollup, and we’re not going to pretend it is. If you manage a handful of people directly and want to see their combined Planner load without opening each of their names one at a time, that’s precisely what it does — crosstowntech.com/planner. If what you actually need is the full multi-layer org subtree, that’s a real Graph build (recursive directReports calls per layer) — the pipeline above is your starting point.