Infor user licensing is enforced differently in each of Infor’s ERP product families, because many of them came from separate companies before Infor acquired them. Infor LN, the former Baan, uses a central licence server, Infor Solution License Manager (SLM).[2] Infor SyteLine and other applications built on the Mongoose framework, such as Factory Track, count license module tokens.[3][5] Infor M3 validates a licence key and supports a limited user type.[8][6] Infor Public Sector assigns user licences per module.[9]
These controls matter for compliance, but they do not settle it. The On-Premises terms allow a security code to stop the software running “for more than the maximum number of users specified in an Order Form”.[12] Infor’s audit FAQ still says that “You cannot rely solely on the security key to ensure compliance with your license agreement”.[11]
Editions
The products in this article are licensed by module rather than by edition. In SyteLine, license modules control access to forms, IDOs and features such as the Credit Card and Tax interfaces, country and industry packs, portals, employee self-service and service management.[4] In Public Sector, “Each user license lets an employee use a specific module, such as Customer Service or Building Permits.”[10] For SLM-licensed products, “Depending on the Infor pricing strategy, a restricted set of license types can be assigned to a specific application”. Some applications accept any licence type, and others accept only server licences.[1]
Metrics
Solution License Manager (Infor LN and Baan)
SLM is “the license manager for the majority of the Infor LN and Infor Baan products”, and its installation “is mandatory”.[2] The documentation divides licence types into user locking and node locking.[1]
| Licence type | Infor definition | Catalog row |
|---|---|---|
| Concurrent User | “A user-locking license in which a pool of concurrent users can use the adopting application”[1] | Concurrent User License |
| Named User | “A user-locking license in which a pool of specific named users can use the adopting application”[1] | Named User License |
| Heavy and Light User | Named user licences for users in the heavy or light user role; “The adopting application specifies what this role implies”[2] | Heavy, Light |
| Server | A node-locking licence for a pool of specific named server or desktop computers[1] | Server License |
| Instance | Instance locking for named instances; registered as server licensing from SLM 2.5[1] | Instance License |
| Desktop | A set of adopting applications linked to named server or desktop computers[1] | Desktop License |
The licence file is an XML file holding the agreement’s licence information: the activation key, the customer, the host IDs and the application licences. The SLM guide notes that licence quantities can usually be found in “Schedule A” of the Software License Agreement.[2]
SyteLine, Factory Track and other Mongoose applications
On premises, SyteLine needs a licence document listing each license module and its quantity. “Each module that you purchase has a certain number of tokens available for users to consume”.[3] A site is licensed either for named users (SyteLine named user license) or for concurrent logins (SyteLine concurrent login license): “You cannot mix types.”[3] In the cloud, the usage-tracking model applies instead.[4]
M3 and Public Sector
M3 Foundation “validates the license key”, and “The number of logged on users is continuously monitored and validated against the license key”.[8] M3 also has a limited license user type for users “who can access a limited number of functions according to the customer agreement”.[7] Infor Public Sector agencies choose a named user or concurrent user model, and buy server licences in addition.[9][10]
Counting / floors
SLM named users. The Software License and Support Agreement states how many named users may use an application. The SLM server keeps the list of permitted users and “will reject a license request” from an unknown user name. “Infor only validates the amount of named users. Infor never knows the specific names of these users.” SLM checks the user name together with the desktop, and “Each desktop on which this user runs the application decreases the number of licenses by one”.[1] In LN, the License Administration sessions can link SLM product IDs to users from the authorization system and synchronize the named user list.[1] Catalog proof: Each extra desktop of a named user consumes a licence; SLM validates only the number of named users; Licence types per application follow Infor pricing strategy.
SLM availability. An SLM cluster has one to four servers. In a group without high availability support, if one server “does not run for longer than 72 hours (grace period)”, the number of licences is reduced.[2] Catalog proof: A stopped SLM server reduces licences after a 72-hour grace period.
SyteLine named users. “Named license users are only allowed one active login to a SyteLine site, and that login consumes a license.” A token is consumed when the user is assigned to a module and returned when the assignment is removed.[3] Catalog proof: SyteLine named users get one active login per site.
SyteLine concurrent logins. Any number of users can be associated with a module. At login, a token is consumed for each module that applies to the user and the session type. “License module tokens consumed during a user’s session are returned to the available pool when the user logs off.”[5] A usage-tracking licence bypasses token counting altogether.[5] Catalog proof: SyteLine concurrent tokens are taken at login and returned at logoff.
Multi-site. With several sites in one database, one licence document covers all of them, and the named or concurrent limits apply across all sites. With one site per database and no intranet licensing, each site keeps its own tokens. A user logged into several sites “uses a license token for each of those logins in each site”. Intranet licensing lets a master site validate licences for the participating sites, where a named user may have one login at each site.[3] Catalog proof: Separate-database SyteLine sites count each login separately; SyteLine sites cannot mix named and concurrent licences; SyteLine intranet named users get one login per participating site.
Special users and automation. The “sa” user needs no licence, but only one instance may be logged in. Every customer receives a multi-session user, SL_Internal, for web service automation. Assigning a multi-session user to a module consumes as many tokens as it has defined concurrent sessions. ION retrieves BODs over a direct connection, “so no license token is required”.[3] Catalog proof: SyteLine multi-session users consume one token per defined session.
Demo and pilot databases. These “must be licensed and must meet the requirements in the Infor Non-Production Server Licensing Policy”. Infor supplies that policy on request; it is not published.[3] Catalog proof: SyteLine demo and pilot databases must be licensed.
M3 limited users. A limited user may run only the programs listed for one limited role in SES403, with a default maximum of 10. “API programs are part of the maximum number of programs for a limited role. For example, OIS100 and OIS100MI count as two programs.” The maximum “cannot be overridden by the customer without advice from Infor”.[6] Users that never log on, such as customer contacts, can be created in MNS150 as non-licensed users.[7] Catalog proof: M3 limited users count API programs towards their maximum; M3 users who never log on can be non-licensed users; M3 Foundation validates logged-on users against the licence key.
Public Sector. Under the concurrent model, “Infor Public Sector adds one to the concurrent user count for each license that user is assigned”, from login to logout, whichever modules are used. “Infor charges more per license under the concurrent model”.[9] Catalog proof: Public Sector concurrent users count once per assigned module; Public Sector concurrent licences cost more per licence.
Virtualization & partitioning
Node-locking licences (Server, Instance, Desktop) are bound to named machines. The SLM Servers File records “the name and identification number of the server machine”.[2] An on-premises SyteLine demo database needs a licence key specific to that database and the server it resides on.[3] None of the retrieved documents sets a processor, core or virtual machine counting rule.
Cloud / BYOL
The cloud changes how SyteLine is licensed. The 2020 guide said that in the cloud “All licenses are named user licenses” and that Infor applies the licences.[3] The 2026.10 documentation says that “Infor uses the ‘usage-tracking’ model for cloud environments”. By default users can reach any form, and Infor checks compliance by “snapshot” audit through database queries. The system administrator must therefore restrict access to unlicensed modules.[4] Catalog proof: SyteLine cloud uses usage tracking with snapshot audits; SyteLine cloud administrators must restrict unlicensed modules.
Programs
The product documentation describes no licensing programme. Support, maintenance lifecycle and audit terms are in Infor on-premises terms and licence audits. Infor’s audit software collects “the products, the user by ID, and the workstation by ID” and produces named or concurrent user counts. Those counts can be compared with the SLM user list, the SyteLine License Module Concurrent User Counts form, or the M3 coordinator log.[11][3][8]
Out of scope
This page does not cover the Infor Non-Production Server Licensing Policy (not public), product-specific licence module lists, Infor EAM and Infor CloudSuite HCM licensing, or LX and BPCS licensing, whose public guide could not be retrieved.