I originally shared this on LinkedIn — Smarter Permission Set Design in IFS Cloud — and it seemed to resonate with a lot of folks, so I figured it was worth a share here as well.
Hope you find it useful! Feel free to connect with me on LinkedIn and swap ideas.
Most ERP teams don’t think twice about how they structure permissions — until the week before go-live or the day the system breaks.
If you've ever worked on an IFS Cloud implementation and suddenly hit a wall when assigning roles to users, you’ve may have encountered the Oracle role limitation. It’s a quiet constraint — but a critical one. Each user can only be granted around 48 roles, including both END_USER and FUNCTIONAL permission sets.
In large, complex organizations, or even just well-designed implementations, it's surprisingly easy to hit that ceiling.
After navigating these challenges on multiple projects, I want to share a framework that’s helps us stay organized, scalable, and within Oracle's limits — without compromising access or maintainability.
The Problem with Mega Roles
A common shortcut is to assign sweeping roles like FR_P2P or FR_WHSE_MGMT that grant access to entire modules — procurement, warehouse, AP, etc. At first, this seems efficient.
But soon, those roles:
- Become impossible to maintain
- Lead to over-permissioned users
- Obscure who can access what (an audit nightmare)
- Increase risk of hitting the Oracle limit
Worse, when you need to troubleshoot or tweak access, these mega-roles give you no clear place to start.
The Better Approach: Granular + Modular
Instead of assigning roles based on modules, design your roles around business responsibilities and subprocesses.
Step 1: Define Business Roles (END_USER Sets)
These are high-level user groups like:
- Buyer
- Warehouse Clerk
- AP Clerk
- Shipping/Receiving Manager
Step 2: Build Functional Roles
Each END_USER role is made up of reusable, task-specific FUNCTIONAL roles. Examples:
- FUNC_PUR_ORDER_CREATE: Create new POs
- FUNC_PUR_ORDER_APPROVE: Approve POs
- FUNC_PO_VIEW: View PO details
- FUNC_WHSE_COUNTING: Perform physical counts
- FUNC_WHSE_ANALYTICS: Access inventory history and reports
These are modular, easy to assign, and even easier to audit.
Use the Navigator as a Blueprint
Here’s a trick I’ve found effective: use Level 2 of the IFS Navigator structure to define your functional roles. IFS already breaks its processes down into logical folders — just follow that lead.
For example:
- Warehouse Management>Counting >Warehouse Management>Quantity in Stock
- Warehouse Management>Transaction History >Warehouse Management>Location
- Warehouse Management>Part >Warehouse Management>Handling Units
- Shipment Management>Outbound Shipment
- Shipment Management>Inbound Shipment
You can grant permissions to these Functional Roles via the Manage by Navigator command, making this strategy both scalable and consistent.
Read-Only vs Full Access
When designing roles, it's often valuable to distinguish between read-only and read/write access.
Example:
- FUNC_PUR_ORDER_MANAGE – create/edit/release POs
- FUNC_PUR_ORDER_VIEW – view POs without editing
Use Grant for full access and Grant Query for read-only in your functional roles.
This allows you to safely give visibility to roles like AP or Finance without exposing sensitive actions.
Stay Under the Oracle Limit
The limit is ~48 roles per user (Oracle database roles, not an IFS-specific constraint).
Safe Targets:
- 30–35 functional roles system-wide
- 5–10 functional roles per END_USER set
- Max 1 END_USER permission set per user
Track role counts with a spreadsheet or role matrix — and avoid assigning both functional and end-user sets directly to users.
Why This Matters
A well-designed permission strategy doesn’t just keep things neat — it:
- Makes onboarding faster
- Improves audit transparency
- Reduces the risk of privilege creep
- Keeps your implementation stable and scalable
I’ve found that spending extra time upfront on permission set design pays off tenfold later — during UAT, go-live, audits, and user support.
Let’s Keep the Conversation Going
Are you working through permission strategy in IFS Cloud or another ERP?
What challenges are you facing? How are you managing read-only vs. full access, or preventing role sprawl?
Drop your thoughts in the comments or connect with me directly — always happy to share what’s worked (and what hasn’t).
Tags:
#IFSCloud #ERP #Permissions #Oracle #RoleDesign #ERPImplementation #IFS #SolutionArchitecture
