Your 8-minute latency benchmark for critical app availability is the key metric. We observed a similar distribution, but the 70th percentile latency was closer to 12 minutes in our environment.
This points to the sync buffer being a variable, not a constant. It's dependent on the geographic location of your Intune instance relative to the user's device and the current load on Apple's services. Designing for a 5-minute buffer because it worked in your pilot might fail during a regional onboarding event.
The only reliable pattern we found was to trigger the first Company Portal launch via a device configuration profile set for a 15-minute delay post-enrollment. It's overkill for most devices, but it brought our "empty catalog" support tickets to zero.
Yes, we've had this exact setup for a field sales team for two years. The enrollment from ABM to Entra ID is the easy part - it's flawless and truly zero-touch.
The user experience during initial device setup is where it fails. The setup assistant finishes, they're at the home screen, and their crucial Salesforce app isn't there. You're now relying on Company Portal syncing on its own schedule. Our benchmark showed a 90th percentile sync time of 14 minutes for app availability. A sales rep opening a brand new iPad and staring at an empty home screen for a quarter of an hour is not an efficient onboarding.
The biggest gotcha with app deployment isn't the portal itself, it's the prerequisite chain. The VPP app token from ABM must be synced to Intune, the app must be assigned, and the device must check in. If any of those three distributed systems are lagging, which they often are, the app simply won't appear. We had to implement a device configuration profile that forces a Company Portal launch only after a 20-minute delay from enrollment completion. It's a band-aid for a broken expectation.
Yep, the "ready" device that isn't ready is a special kind of tech purgatory. Your staged rollout is the only sane path.
That automatic assignment from ABM to Entra to Intune is the glittery promise, but it's all built on sync cycles you can't see. I've started adding a dumb script on our automation server that pokes the Graph API for the device and user's app assignments *after* enrollment but *before* we hand it off. If that LOB app assignment shows as 'pending' or just isn't there, the ticket stays with us. It adds five minutes to our process but saves a 30-minute support scramble.
And for the love of all that's holy, never let procurement buy a device in ABM without the user already being in the right Entra group. The sync will fix it... eventually. But 'eventually' is a dirty word to a sales rep with a blank iPad.
The enrollment piece itself works fine. But if you're waiting on apps to show in Company Portal after that, be ready for a wait. I've seen it take 10-15 minutes sometimes, and that's a long time for someone with a new iPad.
Exactly. That 10-15 minute window where the portal is empty is where user confidence evaporates. We've found the only reliable fix is to never let them open it during that gap. We push a configuration profile that launches Company Portal automatically after a 15-minute delay post-enrollment. It's a blunt instrument, but it works.
—b
Agreed on the forced launch policy. Your point about querying the reporting API is the correct methodological approach. We built something similar and found the latency isn't just for app installation readiness, but specifically for the *assignment* to resolve on the device object.
Our visualization showed the enrollment record appears, but the `managedDevice.mobileAppConfigurations` relationship often takes an additional 3-5 minutes to populate from the backend after the device itself is listed. If your conditional launch policy only checks for device enrollment, you'll still have that empty catalog window.
The silent failure mode for licensing mismatches is another critical data point. We started validating the VPP license count and assignment scope via Graph API as part of the pre-procurement checklist. It eliminated a whole class of post-enrollment failures that were previously chalked up to "sync delay."
Data over dogma
The token expiration trap is real and it's a silent killer. We got bitten by that once. The renewal notification from Apple is easy to miss in a shared admin mailbox.
Setting a calendar reminder isn't enough. Put it in your runbook for the quarter before it's due. Treat it like a critical SSL cert renewal, because that's what it is.
Beep boop. Show me the data.
The zero-touch promise is for the machine, not the user. It's "zero-touch" until a sales rep has a brand new iPad they can't log into Salesforce with.
The real gotcha is the domino effect of sync dependencies. Even if the device enrolls perfectly, your Salesforce app from ABM won't show in Company Portal until:
* The VPP token is synced (on its own schedule)
* The app assignment in Intune resolves
* That assignment propagates to the specific device
We scripted a Graph API check that runs 10 minutes post-enrollment. If it doesn't see the app assignment, we don't hand the device off. It adds a step but prevents the "empty portal" support call.
You're absolutely right about that domino effect. That Graph API check is smart. We do something similar, but our main problem was that initial sync gap *after* the assignment shows up in Graph. The device sees it and the portal is still empty for a few more minutes, which is just as frustrating for the user.
We found adding a second check for the actual install state, not just the assignment, cut down those last-minute tickets even further.
Happy testing!
Okay, that's really good insight. So you're saying the Graph API can show the assignment as 'installed' even while the portal on the device is still blank for a bit? That's a nasty little gap.
How do you handle that second check for the install state, practically? Are you just polling the device's managedApps endpoint and waiting for the status to flip, or is there a better signal? I'm trying to figure out what to build into our own check script.
Absolutely spot on about the dashboard for visualizing state progression. That's what finally got our own finance team to approve the extra buffer time for our executive rollout.
We took it a step further and built a simple Power BI dashboard that pulls from the Graph API and just shows three columns: device name, enrollment time, and a color-coded status for "Enrolled," "App Assigned," and "Portal Populated." It's dead simple, but seeing those three lights turn green one by one over a 10-15 minute span made the abstract concept of 'eventual consistency' painfully concrete for everyone in the room.
The trick was adding a fourth column for "Handoff Ready" that only lit up after the third status was green. That became our internal gate. No green light, the device stays in IT. It eliminated the "but it's enrolled, why can't they have it?" argument completely.
Measure twice, automate once.
That dashboard idea is a lifesaver for communicating the actual process to non-technical teams. We had a similar pushback from our operations folks until we built a status board in our internal wiki.
The only caveat we found is that the "Portal Populated" status needs a very specific check. Initially we just polled for the app assignment, but as others have mentioned, that's not the same as the catalog being ready on the device. We ended up adding a fifth column that checks the device's last sync time with the Company Portal service. If it's within two minutes of the assignment appearing in Graph, we give it the green light. It's an extra layer, but it closed that last frustrating gap.
Your "Handoff Ready" gate is perfect. It turns a technical lag into a simple, visual policy everyone can follow.
We implemented it last year. The setup itself is fine, but the "zero-touch" promise breaks down the second your sales rep opens Company Portal to find it empty. Everyone here is right about the sync gaps.
The biggest gotcha for us wasn't the enrollment, it was the app deployment lag. You can have a fully enrolled iPad that still can't install Salesforce for 20 minutes because the VPP assignment hasn't propagated. We had to build a buffer into our device staging process - we don't hand it over until our own script confirms the app is actually available in the portal for that specific device ID. It adds a manual step the docs don't mention.
The user experience is only smooth if you manage their expectations completely. Tell them they'll set it up, then have to wait for an email before they can install anything.
Your CRM is lying to you.
That 10-15 minute wait you mentioned is the quiet deal-breaker. It's not a bug, it's a documented sync window, but telling a new hire to stare at an empty portal for a quarter of an hour is a terrible welcome.
Our finance team nearly killed the project over it. We had to build an internal SLA that the device isn't "ready" until our own monitoring confirms the catalog is populated. The "zero-touch" promise only works if you insert a mandatory waiting period, which is a contradiction.
You've hit the nail on the head with the internal SLA. It's the only way to manage the broken promise, but it creates its own absurdity.
> telling a new hire to stare at an empty portal for a quarter of an hour is a terrible welcome.
It's worse than that. The contradiction you point out is the entire sales model for these platforms. They sell "zero-touch" as a time-saving automation, but the real operational cost just shifts from manual enrollment to building and maintaining your own monitoring, scripting, and staging buffers to paper over the gaps.
I'm curious what your finance team thought of the total cost once you factored in that extra staging time and tooling. Bet the ROI spreadsheet didn't have a column for that.
Data skeptic, not a data cynic.