Most organisations give three people Organization Administrator and stop thinking about it. That works until the day somebody releases a device that was going to Apple for repair, or accepts a terms update nobody wanted, or discovers that the account which configured single sign-on is structurally unable to use it. The permission model in Apple Business is small enough to read in an afternoon and consequential enough to be worth the afternoon.
There is a reason this article sits before identity and before devices rather than after them. Every decision in the rest of this series is made by somebody holding a role, and two of those roles are capable of actions that cannot be undone. Working out the delegation afterwards means working it out with an estate already in the register, which is when people start granting the top role because it is quicker than reading the matrix.
The shape of the model
Apple Business separates the role from its scope, and the separation is the part worth understanding. A role is a bundle of permissions. An assignment attaches that role to a person for a particular organisational unit. The same person can hold different roles in different units, and Apple’s rule for the top of the tree is precise: a role assigned at the initial organisation can be used across every organisational unit, while a role assigned to two units other than the initial one works only in those two. Delegation therefore happens by scope, not by inventing narrower roles.
The roles themselves come in two populations. There are four defaults, which are Organization Administrator, IT Administrator, Marketing Administrator and Staff. Then there are custom roles, of which Apple predefines People Manager, Content Manager and Device Enrollment Manager, and allows you to create up to fifteen of your own. Two further custom roles exist only as archaeology: Device API Manager appears if your organisation moved across from Apple Business Manager or Business Essentials carrying existing API accounts, and Brand Manager appears if it moved from Apple Business Connect. If you see either in a tenant you did not build, you are looking at a migration artefact rather than a design decision.
Permissions themselves are grouped into five categories, covering the organisation, people, devices, apps and services, and brands, and Apple publishes fourteen separate permission tables underneath them. That is more granularity than most organisations of a hundred and forty people will ever need, and it is exactly the right amount for one of four thousand. What matters at any size is the management matrix rather than the permission count.
Who can promote whom
Apple publishes a table stating which roles can manage which other roles, and it is the closest thing Apple Business has to a tiering model. An Organization Administrator can manage other Organization Administrators, IT Administrators, Marketing Administrators, Staff, and every custom role. An IT Administrator can manage other IT Administrators, Staff, and every custom role, but cannot touch Organization Administrator. Marketing Administrator and Staff can manage nobody at all.
That produces a clean boundary and it is worth designing around deliberately. IT Administrator is a genuinely capable role that can build out your entire delegation model, including custom roles, without ever being able to add somebody to the tier that accepts Apple’s legal agreements. In an estate where the device work is done by a managed service provider or a helpdesk team, IT Administrator is where they belong, and it is a boundary the product enforces rather than one you have to trust people to respect.
IT Administrator can build your whole delegation model and cannot promote anyone into the tier that signs Apple’s agreements. Use that.
The tier above it is capped, and the cap is low. Apple allows ten Organization Administrators in total, stated as the initial user plus up to nine more, and it is repeated on two separate pages so it is not a documentation slip. Ten sounds generous until you remember that this is the only role which can accept updated terms and conditions, and that until somebody accepts them, most of the functionality in Apple Business is unavailable. That is a business-hours outage caused by a legal document, and the mitigation is banal: hold at least two, in different time zones or at least on different holiday schedules, and do not spend the ten on people whose actual job is device enrolment.
The role that cannot use what it configures
Here is the piece of the model that surprises everyone, and it is a deliberate design rather than an oversight. Apple’s rule is that users with the role of Organization Administrator, or any custom role holding the permissions to set up and configure federation and connect to an identity provider, cannot sign in using federated authentication. They can only manage the federation process.
Read the two halves of that separately, because they behave differently. Every Organization Administrator is excluded by virtue of the role, whether or not they have ever touched federation. Custom roles are excluded by virtue of the permission, so only the ones you granted it to. Apple’s sentence does not mention IT Administrator at all, which leaves the position of your most capable working role genuinely unstated. Assume nothing there: if you intend an IT Administrator to sign in with their Entra credential, test exactly that with one account before you build a rollout on it.
People discover this by trying to test federation with their own Organization Administrator account and finding it does not work, then spending an hour convinced the configuration is broken. It is not. Apple has built the break-glass account into the product. The consequence is genuinely useful, and it is worth stating positively rather than as a limitation: an organisation cannot lock itself out of Apple Business by breaking its Entra ID tenant, because the ten accounts at the top of the tree never authenticate through it.
What that demands of you is that those accounts are treated as break-glass accounts in the way your Entra ID break-glass accounts already are. Their passwords live wherever your emergency credentials live. Their addresses are on your domain but they authenticate against Apple, not against you, which means your Conditional Access policies do not cover them and your password expiry does not either. If your privileged access model has a register of accounts that sit outside the identity perimeter, these belong on it. The account inventory work in [PIM 1] is the right frame to borrow.
Organizational units, and a word that now means something else
Apple used to call these Locations. In Apple Business they are organizational units, and the old word has been reassigned to mean a physical place where an organisation conducts business with customers, which belongs to the marketing half of the platform. Two things follow. Any documentation or blog post you find that discusses Locations in a device management context is describing the pre-2026 product, and Apple School Manager, which kept Locations, is describing a different one. Neither is wrong. Both will mislead you.
Functionally an organizational unit is a container for licence entitlement and a scope for permissions. Your first one is created automatically and named after your organisation, and it is the single unit you cannot edit. Additional units can mirror physical sites or a reporting structure, and apps and books are provisioned to specific units, which is the reason most organisations end up creating any. Deleting a unit requires transferring its accounts and its app and book licences somewhere else first, so they are cheap to create and awkward to remove.
My advice for an estate under a few hundred devices is to resist creating them. A single unit keeps your licence pool undivided, which means you never discover that the twelve spare licences you were counting on are stranded in a unit the assignment does not reach. Create a second unit when you have a real reason: a subsidiary with its own budget, a region with its own app catalogue, or a delegation boundary you want the product to enforce rather than your process. Creating them because the estate has offices is how you end up doing licence arithmetic across four pools every time somebody joins.
One caution attaches to the initial unit specifically, and it reaches forward into app licensing. Its content token is the artefact that lets Intune distribute volume purchased apps, and on an organisation that migrated from Apple Business Manager or Apple Business Essentials that token can be taken away for good by enabling Apple’s built in device management service before the token has ever carried an assignment. The recovery is to create another organisational unit and move licences into it, which works and is documented, so this costs you an afternoon rather than your app estate. That is covered where it belongs in [AB 13]. The reason it appears here is that from the settings screen it looks like an organisational unit decision, and the unit it damages is the one you cannot rename or rebuild.
The permission nobody granted
There is one authority in Apple Business that is not granted to a person at all. When you connect a device management service, Apple can give that service the ability to release devices from your organisation without anybody signing into Apple Business. Whether it arrives switched on is, as of writing, something Apple’s own documentation cannot agree with itself about. The page describing device release says the feature is enabled by default when you add a device management service and that you can remove it by deselecting the option. The page that actually walks you through linking an external service tells you not to select the checkbox next to Release Devices unless you want the service to have that ability, which reads as an opt-in.
I am not going to pick between them on your behalf, because the consequence of guessing wrong runs in the expensive direction. Go and look at the checkbox in your own tenant, and look before you finish the linking flow rather than afterwards.
Why it is worth the thirty seconds: releasing a device is not a soft action. Apple is clear that a released device can no longer have its Activation Lock managed through Apple Business, that it needs to be erased and restored, and that if Apple replaces it during a repair the replacement never appears in your organisation at all. The device itself is recoverable, since Apple states you can always add devices back and points at Apple Configurator for doing it. The Activation Lock relationship and the repair replacement are not. So the capability in question is not the power to delete a row, it is the power to sever the parts of the ownership record that cannot be re-established.
Whether you leave it on is a real decision rather than an obvious one. Leaving it on means a wipe-and-retire workflow driven from Intune can finish the job cleanly. Turning it off means every release passes through somebody signed into Apple Business, which is slower and is the correct answer in an estate where the management platform is operated by a third party. What is not defensible is not knowing which state you are in. Check it the day you connect the service, which is the build sheet in [AB 7.1], and record the decision rather than the setting.
A delegation that survives contact with a real organisation
For CatSnackJack, at a hundred and forty seats with a two person IT function and an external partner who does the heavy lifting, the model that works is unglamorous. Two Organization Administrators, both internal, both treated as break-glass because they will also be the accounts that configure federation and therefore cannot use it. The internal IT lead and the partner’s lead engineer hold IT Administrator, which lets them do essentially all the device and identity work and prevents either of them adding somebody to the top tier. The partner’s wider team holds Device Enrollment Manager, scoped to the single organisational unit, which lets them assign and manage devices without touching people or licences. Nobody holds Marketing Administrator, because CatSnackJack does not use the brand half of the platform, and that is worth confirming rather than assuming.
That shape scales up by adding organizational units and re-scoping the existing roles rather than by inventing new ones. The fifteen custom roles are there for organisations with a genuine separation of duties requirement, and reaching for them early produces a permission model nobody can explain to an auditor eighteen months later.
Apple is still moving in this area, which is worth knowing when you write any of it down. On the seventh of July 2026 Apple added separate permissions for viewing organizational units, viewing users and viewing user groups. Three weeks later, on the twenty-ninth, it changed device assignment activity so that anyone holding the assign, unassign or release permissions can see those activities regardless of who initiated them. Both are improvements and both mean a permission matrix documented six months ago is already missing rows. Record the intent of your delegation rather than a snapshot of the checkboxes, and re-read the permission tables when you next review it.
With the organisation verified and the delegation settled, the next part of the series takes on identity: what a Managed Apple Account actually is, what verifying a domain gives you power over, and the thirty day clock you can start against your own employees without meaning to.
Apple Business
‹ Previous: [AB 2.1] Build Sheet: Sign-Up, Verification, and the Organization Profile
Next: [AB 4] Managed Apple Accounts, and the Domain You Are About to Capture ›
