A common misconception is that creating a user automatically gives that person access to everything they need.
In reality, adding a user and granting access are two separate steps.
The user account tells the system who someone is. Security roles tell the system what that person can see and do.
Understanding this distinction can help administrators avoid many of the most common onboarding and access issues.
Why Security Roles Matter
A user may successfully sign in to Infor CloudSuite and still be unable to:
- Access a specific application
- View certain menus
- Open documents
- Complete transactions
- Perform administrative tasks
In most cases, this simply means the appropriate security roles have not yet been assigned.
Understanding the Different Types of Roles
Infor uses several types of roles and access controls to determine what users can see and do. Here is a simple breakdown.
Note: Examples of product-specific and application-specific roles are provided in the Appendix at the end of this article
Role or access type | What it means | When it is used |
|---|
Infor-SuiteUser | Basic end-user access to the portal. | Usually assigned to standard users so they can access the portal experience. |
Product or application security roles | Roles tied to a specific Infor product, application, module, or feature. These roles vary depending on what has been provisioned in your tenant. | Used when a user needs access to a specific Infor application or business process beyond basic portal access. |
Functional Security Roles | A bundle of security roles grouped together for a job function. | Useful when multiple users need the same type of access. |
Portal-ContentAdministrator | Allows a user to manage portal content such as widgets, pages, and workspace content. | Used for people responsible for portal content management. |
MingleAdministrator | Provides broad administrative access to portal functionality. | Used for administrators who manage portal applications, workspaces, widgets, and settings. |
Infor-SystemAdministrator | A system-wide administrator role with access across Infor applications, including Security and Admin Settings. | Should be limited to trusted system administrators only. |
How to Choose the Right Access
Start by asking:
- What does this person need to accomplish?
- Which applications do they need?
- Should they be able to view, edit, approve, or administer?
- Is the access temporary or permanent?
- Are they an employee, consultant, project team member, or administrator?
The goal is not to provide maximum access.
The goal is to provide appropriate access.
Common Security Mistakes
Giving Everyone Administrator Access
This often happens during implementations because it feels faster.
However, it creates unnecessary risk and can make troubleshooting more difficult later.
Forgetting to Review Temporary Access
Consultants and implementation resources frequently require elevated access during deployment.
That access should be reviewed and adjusted after go-live.
Assuming the User Setup Is Complete
A successfully created account does not guarantee the user has the permissions required to perform their role.
Always validate access through testing.
Simple Takeaway
Think of it this way:
User Account = Who the person is.
Security Roles = What the person can do.
The most effective access strategy is one that provides users with exactly what they need to perform their role—no more and no less.
Taking a thoughtful approach to security roles during onboarding will help reduce support requests, improve governance, and create a better experience for everyone using the system.
————————————————————————————————————————————————————————————————————————————————
Appendix: Examples of Product or Application Security Roles
Not every user will see the same roles in every environment. Available roles may vary depending on the Infor products and modules provisioned in your tenant. The examples below are intended to help explain what product-specific or application-specific roles may look like.
Product or application area | Example role names | What they typically support |
|---|
Infor OS Portal | Infor-SuiteUser, Portal-ContentAdministrator, MingleAdministrator, Infor-SystemAdministrator | Access to the portal experience and portal-level administration. |
Infor Document Management (IDM) | IDM-User, IDM-AdvancedUser, IDM-Administrator, IDM-SuperUser, IDM-RelatedInformationUser | Access to document viewing, document management, and IDM administration features. |
ION API / API Gateway | IONAPI-User, IONAPI-Administrator | Access to API-related functions and administration. |
ION / integration tools | Roles such as IONDeskAdmin or other ION-related roles | Access to integration-related functions, depending on the environment configuration. |
M3-related applications | Roles such as M3UI-User, M3MobilityCore-User | Access to M3-related applications, interfaces, or mobility functions. |
Other product-specific applications | Roles vary by product, module, or feature | Access to specific applications, business processes, or modules provisioned in your tenant. |
Important note
Seeing a user in the system does not always mean that the user has the right application access yet. In many cases, the user account has been created successfully, but the appropriate product-specific roles, functional roles, or additional access settings still need to be assigned.
