The right Blueprint, every time: how Iru's Blueprint Routing automates device deployment at enrollment

Enrolling a fleet of devices sounds simple in theory: pick a Blueprint, assign some settings, and you're done. But in practice, most organizations are managing a mix of Mac computers, Windows computers, iPhone devices, iPad devices, kiosk tablets, and meeting room devices, each with their own configurations, user types, and provisioning requirements. Keeping all of that straight at enrollment time, without manual intervention or a tangle of enrollment codes, has historically been one of the more tedious parts of device management.

Blueprint Routing changes that.

In our latest virtual event, Principal Solutions Engineers Ryan Slater and Jim Quilty, joined by Global Director of Solutions Maz Kahale, walked through how Blueprint Routing works, why it was built, and what it means for admins who want more control over the enrollment experience without more complexity.

From Assignment Maps to enrollment time

If you've used Iru's Blueprint model before, you're already familiar with the core idea: a Blueprint defines which Library Items and configurations are in scope for a given set of devices. For simpler environments, a single Blueprint does the job. For more complex ones, the Assignment Map adds conditional logic. If a user belongs to a certain identity provider (IdP) group, or a device meets certain criteria, apply these configurations and not those.

Blueprint Routing takes that same flexible conditional logic and applies it earlier in the process, at enrollment time, before the device has even landed in a Blueprint.

Rather than waiting for a device to check in and then figuring out where it belongs, Blueprint Routing lets you define a set of rules that evaluate the device as it's enrolling. The result? Every device goes directly to the right Blueprint, automatically.

Why this matters

The practical benefits go beyond convenience. A few key scenarios make Blueprint Routing genuinely valuable.

One Automated Device Enrollment (ADE) token for everything. Organizations using Apple Business Manager or Apple School Manager often end up with multiple MDM server assignments and default Blueprints for different device families. Blueprint Routing eliminates that by letting you use a single ADE token across all device types, Mac computers, iPad devices, iPhone devices, and route them intelligently at enrollment based on what they are.

Different personas, properly separated. A corporate iPhone has different configuration requirements than a kiosk tablet or a Zoom room controller. Blueprint Routing sends each device type to the Blueprint that's built for it, without cramming everything into one.

Ecosystem-agnostic. This isn't just for Apple. Blueprint Routing works across Apple, Android, and Windows. The same logic, the same conditions, applied consistently regardless of which platform you're enrolling.

Configuring Blueprint Routing: a walkthrough

In the demo, Jim took attendees through a real-world configuration to show how the setup works.

Blueprint Routing lives in the Enrollment section of Iru. The first thing you'll do is select a default ADE Library Item. This controls the out-of-box experience for devices that go through Blueprint Routing. Think of Blueprint Routing almost like a Blueprint itself: it has its own enrollment record, and it supports both ADE and manual enrollment via a six-digit code.

From there, you build your conditions the same way you would in an Assignment Map. In Jim's example:

• Computers (Mac and Windows) were targeted by device family and routed to an enterprise macOS and Windows Blueprint.
• Corporate mobile devices (iPhone and Android) were targeted by device family and additionally filtered by IdP group membership (EMEA, APAC, and Americas) to ensure user-assigned devices landed in the right Blueprint with the correct Assignment Maps rules in place.
• Kiosk and retail tablets served as the catch-all. Any device that didn't match the other conditions landed in the retail tablet Blueprint.

Once saved, Blueprint Routing evaluates those conditions at enrollment time, just like an Assignment Map evaluates them post-enrollment. Devices land where they're supposed to, without any manual moves.

A few things worth knowing

Blueprint Routing is for enrollment time, not ongoing transitions. If you have devices that frequently change hands between users, Blueprint Routing isn't the right tool for that. For scenarios where devices need to move between Blueprints after enrollment, a conditional block in the Assignment Map, potentially combined with an API-triggered script, is the better approach. Conditions are re-evaluated on every check-in or IdP change, so the right configurations apply naturally without re-enrolling or moving devices manually.

Check your ADE assignment. If you've set a specific default Blueprint in the Automated Device Enrollment section of Iru, that will take precedence over Blueprint Routing. Make sure your ADE assignment is updated to point to Blueprint Routing, and that existing pre-enrollment records are updated too. Changing the default doesn't automatically update devices already waiting in the enrollment queue.

Manual enrollment works too. Blueprint Routing has its own six-digit enrollment code, just like a regular Blueprint. Users on manually enrolled devices can use that code to go through the same routing logic at enrollment time.

Works with Apple School Manager. Blueprint Routing works identically with both Apple Business Manager and Apple School Manager. Once devices are assigned to Iru in either platform, Blueprint Routing takes over from there.

Virtual event Q&A

Q: I prefer using a single Assignment Map because client machines move between users frequently. Is there still a good use case for Blueprint Routing?

Blueprint Routing is designed for enrollment time, not ongoing device transitions. If your devices frequently move between users or use cases and need to shift Blueprints as a result, Assignment Maps handle that better. Conditions are re-evaluated on every check-in or IdP change, so the right configurations apply naturally without needing to re-enroll or move devices manually. Blueprint Routing is best used when you want to make sure devices land in the right place from day one.

Q: What's the best way to have devices automatically assigned to their users prior to enrollment?

The best approach is ADE authentication, configured in the Automated Device Enrollment Library Item. This allows Iru to assign a device to a user at the moment of enrollment. Without that, you'd need to do it manually via the pre-enrollment record in the UI. That said, Blueprint Routing does evaluate IdP-based conditions, like department or group membership, at enrollment time. So even without pre-assignment, devices can land in the correct Blueprint based on user attributes.

Q: How do we confirm Blueprint Routing is working? Are there logs we can review?

Changes to the Blueprint Routing configuration are logged and visible in the Activity section of the platform. For device-level confirmation, the simplest test is enrolling a device and checking whether it lands in the expected Blueprint.

Q: What happens if the ADE Library Item is set to none?

Setting it to none means no customization is applied to the ADE experience. The device will still enroll into Iru, but it will go through the standard consumer setup flow: no pre-configured user account creation, no authentication prompt, no suppressed setup screens. The ADE Library Item specifically controls that initial out-of-box experience.

Q: Can Blueprint Routing be used to route devices based on department or employee location?

Yes. Department is one of the native attributes Iru collects from your IdP integration, alongside job title, email address, and group membership. For location specifically, the most flexible approach is to use IdP groups that represent locations and ingest those into Iru to use in your Blueprint Routing conditions. Jim's demo illustrated this with EMEA, Americas, and APAC groups as a real-world example.

Q: Which conditions in Blueprint Routing are different from those in Assignment Maps?

They're identical. The same conditions are available in both places. The distinction is timing: Blueprint Routing evaluates conditions at enrollment, while Assignment Maps evaluate them continuously on every check-in or IdP change. Depending on what you're trying to accomplish, you might use both in tandem.

Ready to see how Blueprint Routing can simplify your provisioning workflows? Request a demo.