Why does the management portal sometimes show outdated device data?

Intune and Microsoft Entra ID rely on background sync and dynamic evaluation, so changes like renames and group moves are not always reflected immediately in the portals.

Two main behaviors from the provided information explain what is being seen:

1. Dynamic group evaluation is not instant
   When devices enroll or when attributes used in dynamic rules change (such as device name or enrollment profile), Microsoft Entra dynamic device groups can take minutes to hours to update membership. Until the device is re-evaluated and added to the correct dynamic group, any Intune apps and policies targeted to that group will not be applied at the next check-in, and the portal views that depend on that group membership will look “stale”. The documentation explicitly notes:
   • Dynamic grouping "isn't instant" and devices "might not be in the dynamic group for some time, possibly minutes to hours".
   • If fast delivery of apps and policies is important, apps and policies should be assigned to user groups, which are pre-populated and do not suffer from this delay.
2. Device actions and names are scoped differently
   • The rename device action in Intune changes the Device name displayed in the Intune admin center, not the management name or the name shown in the Company Portal.
   • Conversely, renaming from the Company Portal website only changes the name as seen in Company Portal and does not change the device name or management name in the Intune admin center.
   This can make it appear that the portal is “out of date” when in fact different names are being shown in different places by design.

Regarding forcing a refresh:

• A device check-in/sync (for example, using the self-service Sync/Check Status action from Company Portal where supported) can help the device send updated data to Intune sooner, but it does not eliminate the delay in dynamic group evaluation in Microsoft Entra ID.
• There is no documented way in this context to bypass the “minutes to hours” dynamic group evaluation delay. For scenarios that require fast-paced deployment, the supported guidance is to:
  • Target apps and policies to user groups instead of dynamic device groups where possible.
  • Be aware that dynamic device group membership and related portal views will not update in real time.

So, the behavior described is expected: device and group data in the portals can lag behind local changes due to non-instant dynamic group processing and the separation between different device name surfaces. A full “force now” for all back-end evaluations is not available in the provided guidance; instead, design of assignments (favoring user groups) and use of device sync/check-in are the recommended mitigations.

References:

• Common questions, answers, and scenarios with policies and profiles in Microsoft Intune
• Device action: rename (android)
• Device action: rename (windows)
• How to Configure the Intune Company Portal Apps, Company Portal Website, and Intune App
• Rename your device from the Company Portal website

I think portal’s just reading an old devReg shard… it only updates when that backend rolls; earliest bump is Intune→open device→Sync once→then sign‑out/in on the box, that’s when it usually flips.

Hi Yuso Faisyahhhhh,

What you’re experiencing is a result of how Intune and Azure AD handle synchronization across different services. The system is designed around “eventual consistency,” which means changes made locally (like renaming a device or moving it to a new group) may take some time to fully propagate across all portals.

In most cases, updates should appear within a few hours, but depending on background sync cycles, caching, and replication delays, it can sometimes take longer. Unfortunately, there isn’t a direct “force refresh” button that instantly updates all portals. What you can do is manually trigger a device sync from the Intune portal or from the device itself, which often speeds things up. Clearing browser cache or refreshing the session can also help ensure you’re not seeing stale data.

The best practice is to plan for a short delay window and use manual sync when immediate consistency is critical. Microsoft continues to improve synchronization times, but the distributed nature of these services means some lag is unavoidable.

I hope this explanation helps you better understand what’s happening and gives you a few practical steps to work around it. If this answer is helpful, please don’t forget to hit “Accept Answer”.

Jason.