Introduction
When we work with SharePoint permissions, we typically use names such as Full Control, Edit, Contribute, or Read. But when we start using Power Automate or SharePoint APIs to manage permissions, these names no longer work. SharePoint instead expects a Role Definition ID, which represents each permission level.
For example, "Full Control" is not passed as a word - it is passed as 1073741829. This small detail is critical when managing permissions in SharePoint using Power Automate or APIs.
What is a Role Definition ID?
A Role Definition ID is the internal numeric value that SharePoint uses to represent a permission level.
Every standard permission in SharePoint has a fixed ID.
| Permission Level | Role Definition ID |
|---|
| Full Control | 1073741829 |
| Design | 1073741828 |
| Edit | 1073741830 |
| Contribute | 1073741827 |
| Read | 1073741826 |
| View Only | 1073741924 |
| Restricted View | 1073741926 |
| Limited Access | 1073741825 |
These IDs are the same in all SharePoint Online tenants and are used whenever permissions are assigned using Power Automate, REST API, or other automation tools.
How Role Definition IDs Work Internally
When you give a user access in SharePoint, it does not store the text Read or Edit.
It only stores the Role Definition ID.
So internally SharePoint saves something like:
User A -> 1073741826
User B -> 1073741829
Later SharePoint converts these numbers back to permission names when showing them in the UI.
This is why when you use Power Automate or APIs, you must send the Role Definition ID instead of the permission name.
Why SharePoint Uses Numbers Instead of Names
SharePoint uses numbers because:
Numbers are faster to process
They work across all languages
They keep permissions consistent
So even if your site language is different, 1073741826 will always mean Read.
Why Role Definition IDs Are Used
Because SharePoint stores permissions as numbers, any automation tool must send those numbers.
For example, if you want to give someone Read access, you do not send “Read”.
You must send 1073741826.
If you send the wrong ID, the user may get the wrong permission or the request may fail.
How Role Definition IDs Work Internally
Simple Use Case
Assigning Unique Item-Level Permissions: In Power Automate, when we break permission inheritance on a SharePoint item and assign unique access to a user, a SharePoint group, or an Office 365 group, we must use the Role Definition ID (like 1073741826 for Read) because SharePoint APIs only accept permission levels in numeric ID format.
Giving Access to a Site or List: When we want to give a user or group access to a whole SharePoint site or a specific list, we use the Role Definition ID to specify the permission level like Read, Edit, or Full Control.
Updating Permissions When Ownership Changes: If a document or list item is reassigned to a new owner, we remove the old user's permissions and give the new owner the correct access using the Role Definition ID.
Automatically Granting Access to Files or Folders: When a new file or folder is created, a flow can automatically grant the relevant team the required permission using the Role Definition ID so they can view or edit it
Real-World Example
Suppose you have a Contracts library.
Rules:
In Power Automate, this will be:
| Team | Role Definition ID |
|---|
| Finance | 1073741829 |
| Legal | 1073741830 |
| Others | 1073741826 |
When a file is uploaded, the flow automatically applies the correct permission using these Role Definition IDs.
Role Definition vs Role Assignment
| Team | Meaning |
|---|
| Role Definition | The permission level (Read, Edit, Full Control) |
| Role Assignment | Who gets that permission (User or Group) |
So SharePoint creates a Role Assignment using a Role Definition ID.
Conclusion
In short, Role Definition IDs are simple numbers that SharePoint uses for permissions, and they make it easy to give or remove access for users, groups, or teams using Power Automate or APIs.