I'm setting up a new device management system for our sales team. We're a mixed environment with Salesforce on iPads and iPhones.
I've seen Microsoft's docs about integrating Entra ID with Apple Business Manager for automated device enrollment. It sounds efficient, but I'm looking for real-world feedback.
Has anyone actually implemented this? How smooth was the setup for your users? Specifically, I'm curious about the user experience during the initial device setup and if there were any gotchas with app deployment from the Company Portal.
We rolled this out for our field techs last quarter. The setup itself is pretty straightforward if you follow Microsoft's connector docs to the letter.
The gotcha for us was app deployment timing. If a user rushes through the initial setup, sometimes the Company Portal and required apps haven't finished pushing from Intune by the time they hit the home screen. They see a blank device and panic. We had to create a simple one-pager telling them to wait 5-10 minutes and then open Company Portal to trigger the final sync.
Overall it's been solid for zero-touch enrollment, but that initial lag caused some confusion.
terraform and chill
That initial sync lag is a common pain point. We addressed it by configuring a device enrollment restriction policy that forces the Company Portal to launch automatically post-enrollment, before the user hits the home screen. This acts as a built-in pause and immediate sync trigger.
You can set this in the Intune admin center under Enrollment > Apple enrollment > Enrollment program tokens > select your token > then enable "Install Company Portal during setup assistant". The device will open Company Portal right after the Setup Assistant completes, which typically pulls down the required apps within a minute or two. It eliminated the need for instructional handouts in our case.
The trade-off is a slightly longer, managed feeling setup flow, but it's more reliable than hoping users wait or manually open the portal later.
It's smooth once you get past the initial sync hiccup everyone's talking about. The real trick is testing the enrollment with the exact apps your sales team needs, like Salesforce Mobile. Sometimes app assignments based on Entra groups can take an extra sync cycle to kick in.
Made that mistake once, handed a sales rep a "ready" iPad that was missing their main app. The look they gave me could have soured milk. 😅 Now I do a staged rollout with a pilot group first.
Biggest plus is the automated assignment. Buy a device in Apple Business Manager, assign it to a user in Entra, and it just lands in their Intune. The user experience is mostly "turn it on and sign in," which is what you want. Just make sure your network isn't blocking anything during that first setup.
Deploy with love
The point about testing with the exact apps is the entire ROI argument. People skip it to meet a deadline, then waste triple the hours on support calls. Your pilot group is the right call.
We also ran into the sync delay on app assignments. We found it wasn't just about groups, sometimes the app license itself in ABM needs to sync fully before Intune can deploy it. Adding a 24-hour buffer between purchasing an app volume license in ABM and assigning it in Intune solved most of those "missing app" cases.
And +1 on checking network blocks. One of our satellite offices had a proxy that interfered with the initial Apple activation check, which looked identical to a sync delay. Caused a lot of wasted time.
—hd
We've been running this setup for our field teams for about a year now. The setup for users is genuinely smooth *if* you account for the app sync lag everyone's mentioned. I'll echo the policy tip about forcing Company Portal to launch at the end of setup, it's a lifesaver.
One specific gotcha we hit with Salesforce Mobile - make sure your app configuration policies in Intune are rock solid, especially if you're pushing managed app config. Sometimes the config would apply before the app itself finished installing, causing a weird blank state in Salesforce on first launch. A simple "close and reopen the app" fixed it, but it's another minor UX hiccup to test for in your pilot.
Data is the new oil - but it's usually crude.
That Salesforce Mobile config timing is a real one. We saw the same thing, and our fix was to add a small delay in the app config assignment by linking it to a group membership that only applies after the device is fully enrolled. It's a bit of a hack, but it ensures the app's settled before the config hits.
Your point about testing the managed app config in the pilot is spot on. It's those little friction points that kill user confidence, even if a restart fixes it. We included "first launch steps" in our quick-start guide just to pre-empt the support call.
The group-membership delay tactic is a clever workaround for the config race condition, but it introduces a dependency on group processing latency, which can be inconsistent. I've found it more reliable to stage the deployment entirely within Intune by using app assignment *intents*.
Instead of assigning the app and its config simultaneously, assign the app as "Required" with the standard install context first. Then, create a separate app configuration policy for Salesforce, but set its assignment to the same group with a *delayed start time* of, say, 4 hours. Intune will process these as distinct operations in sequence, giving the binary ample time to install and initialize before the managed settings are injected. This avoids creating artificial group logic and keeps the control plane within a single service.
The real lesson, which your post underscores, is that these stateful orchestration systems (ABM -> Entra -> Intune -> device) have eventual consistency. Any automation expecting immediate, sequential perfection will fail. Designing for minimum viable synchronization windows is the key.
The delayed start time on the app config policy is a much cleaner solution than playing with group logic. It keeps the orchestration visible and scheduled within a single admin console.
Your point about eventual consistency is the core architectural constraint here. People design flows assuming linear, immediate state transitions, but that's not how these federated systems work at scale. The sync windows aren't a bug, they're a feature of distributed systems that you have to design around.
We ended up building a simple dashboard that polls the Intune graph API to monitor the actual state progression during our pilot: device enrolled, app installed, config applied. Visualizing those gaps was what finally got management to buy into the necessary buffer periods.
FinOps first, hype last
The initial setup is indeed smooth for users, assuming you've accounted for the synchronization delays everyone has identified. My experience aligns with the forced Company Portal launch policy; it's the single most effective configuration to prevent user confusion at the home screen.
Regarding your specific question about app deployment from Company Portal, the primary gotcha isn't the portal itself but the orchestration between Entra ID groups, Intune assignments, and Apple Business Manager. The deployment will fail silently if there's a mismatch in licensing or assignment scope. For your Salesforce use case, you must validate that the app's volume license in ABM is assigned to the correct location and that the Intune terms of use, if any, are accepted *before* the device enrollment attempts to pull it. This precondition check is often overlooked.
We instrumented this by querying the Intune reporting API during our pilot to create a simple state machine visualization. It showed that app installation typically lags 7-12 minutes behind the device enrollment record appearing in Intune, even with a perfect network. Plan for that gap in your user communication or, better, use it to design your app configuration policy timings as mentioned above.
Data over dogma
That bit about "silent failure" due to licensing mismatch is so true and it's a nightmare to trace. I've seen it happen when someone buys the VPP license in ABM under the wrong MDM server location - the app simply won't show as available for assignment in Intune, with no clear error.
Your API-driven state machine is the smart approach. For teams without that, a quick manual check in the ABM portal that the app is assigned to your MDM server *and* shows "Manage in Microsoft Intune" status can save hours. It's a one-time setup thing, but if it's wrong, the whole pipeline breaks quietly.
security by default
Oh absolutely, the setup can be smooth. But the "gotchas" everyone's mentioning about app deployment? They're all about that federated sync delay, which directly impacts the user experience during initial setup.
If a user finishes enrollment and their critical app like Salesforce isn't on the home screen yet, they're calling you. The forced Company Portal launch helps, but they still see an empty catalog. The real fix is building that buffer into your rollout timeline, so the device is *actually* ready before it hits their hands.
One nuance I haven't seen mentioned yet - watch your token expiration in Apple Business Manager. If that annual token isn't renewed before it lapses, the entire app pipeline from ABM to Intune silently halts. New app purchases won't sync, and your "ready" device suddenly isn't. Set a calendar reminder for 11 months out
Yeah, that token expiration got us too. The calendar reminder is key, but it's also worth checking if your MDM provider sends any alerts. Ours didn't, so it just stopped syncing new apps one day.
We also found the silence around token renewal in ABM admin notifications can be deceptive. It might say "connected," but the sync jobs have already failed in the background for days. A quick spot check by trying to assign a new test app is the only real way to know.
You call that a one-pager? That's just admitting the product has a lousy first-run experience.
Wait 5-10 minutes? On a new, expensive device? That's not zero-touch, that's a user-facing failure state they've learned to paper over with instructions. Microsoft's "solid" setup still needs a human babysitter with a stopwatch.
Your stack is too complicated.
The setup is technically smooth, but the efficiency claim depends entirely on your definition of "zero-touch."
From our benchmark logs, the enrollment flow from ABM to Entra ID worked without user intervention. The real friction is the post-enrollment state, as others noted. The user experience during initial device setup is a function of your synchronization buffer.
The primary gotcha with app deployment from Company Portal we measured wasn't the portal UI, but latency. In our test cohort, 30% of devices took over 8 minutes for a critical line-of-business app to appear as available for install in the portal after enrollment completed. If your user opens the portal before that sync, they see an empty catalog and assume failure.
You have to design for that lag or you're just moving the support call from "how do I enroll" to "where's my app."