# Infor M3 Security Settings: Roles, Authorization and Setup

> Source: https://netray.co/erp-help/infor-m3-security-settings-roles-authorization
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

M3 security combines who the user is, the roles they hold, which programs and options a role may use (function authority), and which companies, divisions, facilities and warehouses it may work in (data scope). You set it up by connecting users to roles and roles to authorizations, then audit with the security reports.

## Kind

advanced

## System

infor-m3

## Erp

Infor M3

## Module

Security / Roles / Authorization

## Query

infor m3 security settings

## Alternate Queries

- m3 roles and authorities setup
- m3 function authorization
- m3 user security company division

## Applies To

Infor M3 Business Engine, on-prem and cloud. Identity may come from Infor OS / ION identity or directory services, depending on deployment.

## Steps

### Set up security for a new user group

**Items:**

- Define the job role in business terms first: what they need to enter, view and approve.
- Create or select the M3 role that represents it and connect the programs and options (function authority) it needs. Use the lowest rights that work.
- Connect the role to the companies, divisions, facilities and warehouses the group works in.
- Create the user and connect the role. Set the user's defaults in MNS150, including company and division.
- Check how identity is provided: single sign-on through your identity provider, a directory, or M3-managed passwords.
- Test as the user (or with a test account) by walking through the real process and noting any not-authorized messages.
- Document the role and who approved it, then audit periodically.

## Sections

### The layers

**Body:**

Identity answers who is signing in. Roles are the unit you manage; users should receive access through roles and not through individual exceptions. Function authority is the program and option level: view, create, change, delete. Data scope limits company, division and sometimes facility and warehouse.

Integrations follow the same rules. An MI call runs with the service user's roles, so a missing program authority shows up as a not-authorized error.

### Segregation of duties

**Body:**

Design roles so that no one person can both create a supplier and approve its payments, or create a purchase order and receive it. Split these functions across roles and test combinations that one user might hold.

Document conflicts as a matrix and review it each audit cycle. Where a conflict cannot be avoided, compensate with approval workflows and report review.

### Auditing

**Body:**

- Use the standard security listings in your M3 version, or query the security tables on a reporting replica, to answer which users hold which roles and which roles can run which programs. Export results for the auditor.
- Review dormant users, service accounts with broad rights and temporary access that was never removed.

## Pitfalls

- Granting rights to individual users instead of roles.
- Copying an administrator's access as a shortcut.
- Service accounts with full authority and no owner.
- Forgetting data scope, so a user sees every division.
- No periodic access review.

## Ai Angle

Access review is slow when it means reading security tables by hand. A read-only assistant can list who can run a sensitive program, which users hold conflicting roles and which accounts are dormant, with the query shown. Netray can host it on-prem so identity data stays inside your network.

## Faq

### Do I assign rights to users or roles in M3?

**Answer:** Roles. Connect users to roles and keep individual exceptions to a minimum, because roles are what you can audit and reuse.

### Why does a user get a not-authorized error?

**Answer:** Their roles do not include the program or option, or the company, division or facility is outside their data scope. Compare against a user who can do the task.

### Does the same security apply to API users?

**Answer:** Yes. An API call runs as the authenticated user, so give service accounts a dedicated role with only the programs they call.

## Search terms

infor m3 security settings, m3 roles and authorization, m3 function authority, m3 user security, m3 segregation of duties, m3 access review, m3 service account roles, infor m3 MNS150

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json