Sales Development Agent — Power BI Reporting

Status: Public Preview — behaviour may change.

What it does

Exposes the Sales Development agent's prospect and engagement data as an OData feed you connect Power BI Desktop to directly, so you can build custom reports and dashboards beyond the agent's own built-in performance view. You ask the agent itself for the endpoint URL rather than finding it in an admin screen.

Key facts

Only the agent's Manager can request the reporting endpoint and sign in to Power BI against it — Supervisors (see multi-user access) aren't the intended audience for this.
Two OData tables are exposed: prospects (every prospect regardless of status — queued, active, failed, cancelled, on hold) and engagements (stage, email counts, company detail, activity timestamps for prospects the agent has started working). Join them on EngagementId, which stays blank until a prospect moves from queued to actively engaged.
The endpoint is agent- and region-specific. Don't edit the host or any identifier in the URL Power BI is given — a "page not found" error is the usual symptom of doing so.
Reporting data includes prospect names, emails, company names and full engagement activity — it's personal data by any reasonable definition, and Microsoft explicitly calls out handling it per your org's data policies rather than treating it as anonymous telemetry.
Refresh follows standard Power BI Desktop Refresh; the endpoint pages results itself, so there's no manual paging to build.
If the agent's assigned manager changes, Power BI keeps the old cached credentials and refresh fails until you clear saved data-source permissions and reconnect as the new manager — this isn't automatic.

When to use / skip

Reach for this once a team wants to blend Sales Development agent output with other business data, or needs visuals and slicers the agent's own dashboard doesn't offer — cohort-by-industry breakdowns, longer trend history, combining with pipeline data from elsewhere. Skip it if the built-in reporting already answers the question; standing up and maintaining a Power BI report is ongoing overhead for a preview feature whose backing schema Microsoft hasn't committed to long-term.

Configuration decisions

Who owns the Power BI report once built — it depends on the Manager's own sign-in, so a report built under one person's credentials becomes someone else's maintenance problem the moment that manager changes role or leaves.
Load versus Transform Data when connecting: load raw for a quick dashboard, or shape it in Power Query first if you want cleaner types and fewer columns for a report others will consume.
Where the finished report gets published and shared, given the personal-data warning — this isn't a report to drop in a general workspace without thinking about who can already see prospect-level detail elsewhere.

Gotchas

A queued prospect legitimately has no EngagementId — that's expected behaviour, not a data quality problem, and building a report that filters it out by accident will undercount the pipeline.
Empty tables after a successful connection usually mean the agent hasn't started processing prospects yet, or a Power Query filter has quietly excluded every row — check both before assuming the connection is broken.
Credentials don't follow a manager handover automatically; expect a support ticket the first time a Sales Development agent changes hands with a live Power BI report attached.
The URL is single-use-looking but isn't a secret token in the security sense — treat it as you would any other data-source connection string, not as something to paste into chat or a ticket unnecessarily.

Consultant notes

Mention this early to any client already asking "can we get Sales Development agent data into our existing sales dashboards" — it's a straightforward yes with OData, not a custom integration project.
Flag data-handling sign-off before the first report is built, not after — prospect email and company data flowing into a shared Power BI workspace is exactly the kind of thing that should have a named decision-maker, not just a keen manager doing it because they can.
Because the endpoint is manager-bound, agree an ownership and handover process for the report alongside the agent's own manager/supervisor model — don't let it be a surprise the day someone leaves.
Worth pairing with the existing Sales Development Agent multi-user access doc when scoping a rollout: the two features share the same manager-centric permission model, and clients should understand both before go-live.

Worth revisiting at GA, and if Microsoft adds additional reporting tables beyond prospects and engagements.