If your IT department account syncs Entra ID at the site level rather than the account level, Robin's Entra-based actions (password reset, MFA reset, group membership changes) currently don't work correctly for users synced that way. This is a known, current limitation, not a misconfiguration on your end.
This article describes a limitation that applies only to IT department (ITD) accounts. MSP accounts aren't affected - see Does this affect MSP accounts?
Why this happens
Entra ID continuous sync and Robin's connection to Entra ID are two separate mechanisms, even though both run through the same Microsoft consent flow:
- Continuous sync populates Atera's own Users list from Entra ID. For ITD accounts, this can be configured either at the account level or at the site level (see Entra ID Continuous Sync). Site-level sync exists so that ITDs managing multiple locations, and potentially multiple Entra tenants, can import users into the right site without a single account-wide sync.
- Robin's own connection to Entra ID is what actually runs identity-aware actions, like resetting a password or changing group membership, live against Entra at the moment a user asks. This connection is established once, at the Enterprise application level in your Entra tenant, by assigning the User Administrator directory role to Atera's Enterprise application (see Microsoft Entra ID: enable password resets). For ITD accounts, this is a single, organization-wide connection to one Entra tenant. There's no per-site equivalent of it today.
Note: Changes to Exchange Online, such as adding a user to a distribution list or giving access to a shared mailbox, also need the Exchange Administrator role on Atera's Enterprise application. Without it, those actions fail, while Microsoft 365 group changes keep working with User Administrator alone.
Because continuous sync can be scoped per site while Robin's own Entra connection cannot, a user who exists in Atera only through site-level sync isn't reliably reachable by Robin's org-wide connection. That mismatch is the root of the limitation.
What ITD admins should do
If you want Robin to run Entra-based actions (password reset, MFA reset, group changes) for your users, configure Entra ID continuous sync at the account level, not the site level, for now.
Warning: The two levels override each other. If you configure the integration at the site level for a site that is already mapped at the account level, that site's account-level mappings are removed. Before switching from one level to the other, note your current mappings so you can recreate them.
Does this affect MSP accounts?
No. MSP accounts have always synced Entra ID per customer, and Robin's own Entra connection for MSP accounts is likewise scoped per customer, so the two are already aligned at the same granularity. The mismatch described above is specific to ITD accounts choosing site-level sync over account-level sync.
Note: If several MSP customers share one Entra tenant, assigning the User Administrator role once covers all of them, as long as each of those customers is synced from Entra ID.
