Infor LN Not Authorized to Run This Session: How to Fix It
infor ln you are not authorized to run this session
Also searched as
- infor ln access denied session
- baan you have no authorization for this program
- infor ln user cannot open session security
- infor ln role does not include session
Short answer
Infor LN refuses to open a session with a not authorized message when the logged-in user's assigned role does not include that session, or when the session is blocked for the company they are logged into. Grant the session through Common > Authorization Management > Roles, or check the user's role and company context, and the session opens on retry. In most cases this is a permissions configuration issue, not a bug.
Applies to: Infor LN 10.x (10.5-10.7) role-based authorization model in Common > Authorization Management
Grant a user access to a blocked session
- 1Confirm the exact session code the user is trying to open (visible in the title bar or error detail, for example tdsls4100m000) and note which company they are logged into.
- 2Open Common > Authorization Management > Roles and find the role or roles assigned to the affected user in Common > Authorization Management > Users.
- 3Check whether the session is included in any of the user's assigned roles. If it is missing, add it to the appropriate role rather than creating a one-off exception for a single user.
- 4Verify the role itself is authorized for the company the user is logged into; LN authorization is company-specific, so a role granted in one company does not automatically apply in another.
- 5Check for an explicit deny: some sites restrict a session for a role deliberately as a segregation of duties control, so confirm the restriction is not intentional before changing it.
- 6Save the role change and have the user log off and back on, since role assignments are typically cached for the duration of the session.
- 7If the user still cannot open the session, confirm the session itself is not disabled at the package level in Tools > Development > Sessions, which produces a similar-looking error.
How LN authorization actually works
Infor LN controls session access through roles, not direct user-to-session grants. A user is assigned one or more roles in Common > Authorization Management > Users, and each role lists the sessions, menus, and optionally field-level permissions it grants. The not authorized error simply means none of the user's assigned roles include the session they tried to open.
Authorization in LN is also company-specific. A role that grants a session in one company does not carry over to another company automatically, which is the most common surprise for admins used to simpler, single-company systems. Multi-company and multi-site LN implementations need the role reviewed per company.
Segregation of duties versus misconfiguration
Not every not authorized message is a mistake. Many LN implementations deliberately restrict sessions like approving purchase orders or posting invoices to specific roles as a segregation of duties control, often tied to an internal audit or compliance requirement. Before granting broad access, check whether the restriction was intentional.
A quick way to tell the difference: check whether the session was ever included for that role, or ask the security administrator. If it was removed on purpose, route the request through whatever approval process governs access changes instead of simply re-adding it.
Common places this trips people up
New employees copied from an existing user's role assignment inherit that assignment exactly, including any sessions the original user did not have. If a new hire is missing access another team member has, the template used to create them is usually the problem, not the individual role definition.
Role changes made in a test or acceptance environment do not migrate to production automatically. If access works in a sandbox but not in the live system, confirm the role change was actually transported or re-applied in production.
When it is not a role problem at all
If every user, including an administrator with broad authorization, gets the same error for one specific session, the session itself may be disabled or its menu entry deactivated in Tools > Development > Sessions rather than a role issue. Check the session's own status before spending time on individual role assignments.
Common pitfalls
- !Granting a session to an individual user instead of adding it to their role, which creates an untracked one-off exception that gets lost at the next access review.
- !Forgetting that authorization is company-specific and only fixing access in the company the admin happened to be logged into.
- !Overriding a segregation of duties restriction without checking whether it was placed there deliberately for audit reasons.
- !Assuming a role change takes effect immediately, without the user logging off and back on.
- !Not checking whether the session itself, rather than the user's role, was disabled at the package level.
How an ERP-grounded AI assistant handles this
A grounded assistant over LN's authorization tables can answer why a specific user cannot open a specific session directly, by reading the user's assigned roles, the role's session list, and the company context, instead of an admin clicking through several sessions to piece it together. It can also flag when a requested grant would reopen a segregation of duties gap the organization deliberately closed, surfacing that context before an admin approves the change rather than after.
Frequently asked questions
Which session manages user roles in Infor LN?
Common > Authorization Management > Roles defines what each role can access. Common > Authorization Management > Users assigns one or more roles to each user, and that combination determines which sessions they can open.
Does a role apply across all companies automatically?
No. LN authorization is evaluated per company. A role that includes a session in one company must be separately verified or assigned for any other company the same user needs to work in.
Can a super user bypass authorization checks?
LN does have accounts that bypass most authorization checks, but relying on them as a workaround for a role missing a session is a poor practice. Fix the role instead, so normal accounts stay correctly scoped.
Why does the error come back after I add the session to the role?
The most common reason is the user did not log off and back on after the role change, so their session is still using cached authorization. Ask them to close all LN clients and log back in before retesting.
Related
Infor LN bshell Process Stuck at 100% CPU: How to Diagnose and Fix It
A bshell process pinned at 100% CPU on the Infor LN application server almost always means one session is stuck in a 4GL loop, scanning an unindexed table, or waiting on a database lock. End the session from the Sessions Monitor first, then kill the OS process only if that fails, and check for a blocking database transaction before assuming it is a bug.
Error fixInfor LN DAL Out of Sync After a Custom Field: Cause and Fix
Infor LN throws a DAL, or table, out of sync error, or simply drops a new custom field silently, when a table's dictionary definition is changed but the generated DAL and dependent forms are not regenerated afterward. Running the standard sequence, table compile, DAL generation, then session/form compile, in Tools > Development after every dictionary change resolves it. Skipping any one of the three steps is what causes the mismatch.
Error fixInfor LN Jobs Stuck in Active or Waiting: Fix the Job Daemon
Infor LN background jobs, reports, batch processes and print jobs, get stuck in Active or Waiting status when the job daemon on the enterprise server has stopped or lost its connection, or when a prior job crashed without releasing its status. Restart the job daemon and reset the stuck job's status through the Jobs session, and the queue resumes. A daemon that keeps stopping usually points to a memory, license or database connectivity problem on the server.
Error fixInfor LN Reports Stuck in the Print Queue: Device and Spooler Fix
Infor LN reports and forms stay queued and never reach the printer when the target device definition points to a printer that is offline, or the print listener on the print server has stopped. Check the device's status in Common > Printing > Devices, confirm the underlying OS printer is reachable, and restart the print listener if jobs remain queued after the printer itself is fixed. Most cases trace back to a genuinely offline printer, not an LN bug.
AdvancedHow to extend business logic in Infor LN with DAL2
DAL2 lets you add custom validation, defaulting and calculation logic to Infor LN Enterprise Edition tables by writing a Java business logic handler class and registering it against a table event, without editing the standard DAL. Because the logic sits in your own package rather than inside Infor's base code, it survives upgrades that would otherwise overwrite a direct DAL change.
AdvancedHow to create a custom session in Infor LN Studio
Infor LN Studio's session designer generates a new maintenance, overview or detail session from a table definition, then lets you arrange fields, attach DAL2 validation, and wire menu access, all inside a custom package so the session survives upgrades. Building on a custom table gives the lowest upgrade risk; extending a standard table needs more care and re-testing after every release.
AI for ERPAI for Infor LN: Sessions, BODs, and Engineer-to-Order Work
Add grounded AI to Infor LN 10.x or CloudSuite: natural-language answers over sessions and BODs, agents for project and engineer-to-order work, on-prem options.
AI for ERPAI Agents Over Infor ION API, BODs, and the Infor Data Lake
Build AI agents on Infor ION API Gateway, BODs, and Data Lake, alongside or instead of Infor's own GenAI features, with your choice of model and hosting.
Stuck on Infor LN (Baan ERP)?
Talk to engineers who work inside Infor LN (Baan ERP) every week, and who build private AI that answers these questions from your own ERP data.