In short: In Magento 2, create the admin role collection from its factory and apply its roles filter to get only the roles. Without the filter, the collection also returns one row per admin user, so a straight port of the Magento 1 loop prints users as if they were roles.
You need every admin role in code: its ID and name, to print a list, to fill a dropdown or to check a user against it. In Magento 1 that was Mage::.[1] Magento 1 reached end of life on 30 June 2020, so this guide covers the Magento 2 way, which is a different class and has one trap that the old loop never mentioned.[2]
Before you run anything: the code below only reads data, but it belongs in your own module, so try it on a local copy or a staging site first, never directly on a live store, take a backup, and use it at your own risk.
How do you get the admin roles collection in Magento 2?
Inject Magento\Authorization\Model\ResourceModel\Role\CollectionFactory, create a collection and call setRolesFilter() on it. The collection class is part of Magento's public API (@api, since 100.0.2).[3]
<?php
declare(strict_types=1);
namespace Vendor\Module\Model;
use Magento\Authorization\Model\ResourceModel\Role\CollectionFactory;
class AdminRoleLister
{
public function __construct(private readonly CollectionFactory $collectionFactory)
{
}
/**
* @return array<int, string> role ID => role name
*/
public function getRoles(): array
{
$roles = [];
foreach ($this->collectionFactory->create()->setRolesFilter() as $role) {
$roles[(int) $role->getId()] = (string) $role->getRoleName();
}
return $roles;
}
}
Replace Vendor\Module with your own vendor and module names. Magento generates the factory class for you; you do not write it. Inject AdminRoleLister wherever you need the list (a console command, an admin block, a data provider) and loop over getRoles(). Keep it to admin-side or command-line code: the list of roles is not something to show on the storefront.
Tested on Magento Open Source 2.4.9 (magento/ 100.4.9), PHP 8.4 and MariaDB 11.4, with the built-in Administrators role plus two roles named Support and Catalog editor. The class above printed:
Role ID: 1, Role name: Administrators
Role ID: 3, Role name: Support
Role ID: 4, Role name: Catalog editor
Why does the collection also return the admin users?
The roles filter exists because the collection reads the authorization_role table, and that table holds more than roles. Each admin user also has a row in it, pointing at the role the user belongs to; the collection even has a setUserFilter() method for it.[3]
In a test install with those three roles and four admin users, the unfiltered collection returned seven rows, not three:
| Role ID | role_type |
parent_id |
getRoleName() |
|---|---|---|---|
| 1 | G | 0 | Administrators |
| 2 | U | 1 | labadmin |
| 3 | G | 0 | Support |
| 4 | G | 0 | Catalog editor |
| 5 | U | 3 | Anna |
| 6 | U | 3 | Ben |
| 7 | U | 4 | Carol |
G rows are group roles. In this test the U rows are admin users, and their parent_id is the group role each user is assigned to. More generally, U marks a user-specific ACL role: integrations create U rows too, with an integration user type and a parent_id of 0.[4] Note two details. The role IDs are not consecutive, because the user rows use IDs too (1, 3 and 4 above). And on a user row getRoleName() returns a name of the user (a username or a first name in the test), not a role name. setRolesFilter() adds WHERE role_, which is what limits the list.[3][5] Without setRolesFilter(), the same test printed all seven rows, including "Anna" and "Ben" as role names. A Magento 2 port of the old loop therefore needs the filter.

Magento 1 behaviour was not run for this guide, so there is no claim here about how the old collection behaved on the same point.
How do you use the roles in a dropdown?
The collection can build the option list for you. toOptionArray() returns an array of value (role ID) and label (role name) pairs, so call it on the filtered collection:
$options = $this->collectionFactory->create()->setRolesFilter()->toOptionArray();
In the test it returned three pairs, for Administrators, Support and Catalog editor.[3]
How do you find the role of one admin user?
Load the user and ask for its role. getRole() returns the role model, so getRoleName() and getId() work on it:[6]
$user = $this->userFactory->create()->loadByUsername('anna');
$role = $user->getRole();
echo $role->getRoleName(); // Support
($this->userFactory is Magento\User\Model\UserFactory, injected like the collection factory.) In the test, the user anna came back with the role Support and role ID 3.
How do you list the users of a role?
There is no public method for this on the role collection, but the table layout above gives you a filter: user rows have role_type U and a parent_id equal to the role ID. For role 3 in the test, this found the two Support users:
$members = $this->collectionFactory->create()
->addFieldToFilter('role_type', 'U')
->addFieldToFilter('parent_id', 3);
foreach ($members as $member) {
echo $member->getUserId();
}
This relies on how the table is laid out, not on a documented promise, so check it again after a Magento upgrade. To change what a role may do, or to see its users in the Admin, use System > Permissions > User Roles.[7]
References
Numbers in square brackets in the text link to these sources.
- OpenMage LTS: Mage_Admin_Model_Roles (GitHub) (opens in a new tab)Used for: the Magento 1 admin/roles model named in the old snippet.
- Help Net Security: Magento 1 end of life (opens in a new tab)Used for: Adobe's 30 June 2020 end-of-life date.
- Magento 2.4.9 source: Role Collection (GitHub) (opens in a new tab)Used for: the @api collection, setRolesFilter and toOptionArray.
- Magento 2.4.9 source: Integration AuthorizationService (GitHub) (opens in a new tab)Used for: integrations also creating U rows with a parent ID of 0.
- Magento 2.4.9 source: Acl Role Group (GitHub) (opens in a new tab)Used for: the G value that marks a group role.
- Magento 2.4.9 source: User model (GitHub) (opens in a new tab)Used for: getRole() returning the user's role model.
- Adobe Experience League: User roles (opens in a new tab)Used for: where roles are managed in the Admin.