Populate User Types
Introduction
In the Mendix Pricing Plan, a distinction is made between Internal and External Named Users of a Mendix app. As a customer, you purchase a license for a specific number of Internal users and, optionally, for External users (which are typically cheaper). For accurate user metering, External users must be correctly classified. If they are not, your company may exceed the licensed capacity for Internal users, and Mendix may require you to acquire additional Internal user licenses.
This document helps you set up your apps to ensure accurate metering for your External users. It describes different sample solutions that can help you in External User classification for existing users of your apps.
Definitions
- Named User¹ – an individual authorized by you to have access to your apps with unique login credentials, or an authorized external system that accesses or is accessed by your application.
- Internal User – a Named User who is an employee or contractor of your business.
- External User – a Named User who is not an employee or contractor of your business, and is designated as an External User in the Mendix Platform.
¹You may re-assign the entitlement to access and use your applications from one Named User to another Named User within the same entitlement category (internal or external) once per calendar month.
Background
Every Mendix app has a system module containing an entity UserReportInfo
. This entity has an attribute UserType
that is used to classify end-users as External
or Internal
Users. Your application must set the attribute for all existing and new (external) end users. If it does not, Mendix will classify those users as Internal.
The metering relies on this attribute to ascertain the end-user type and report it back to us.

Classification Options
There are several approaches to classify users as Internal
or External
, ranging from configuration-only to custom development. These options are listed below:
IdP-Based User Classification
The simplest method to set the UserType
is by using the Identity and Access Management (IAM) modules, which require only configuration without the need to develop a microflow. This approach leverages a connection with an Identity Provider (IdP) to classify users. The primary benefit of IdP-based classification is its efficiency, as it typically only requires configuration within the existing IAM modules. Mendix offers you the following IAM modules:
Alternatively, you can build a custom microflow as described in the Populating UserType for Existing Users of an App section below.
When connecting your app with an IdP, set up the UserType
through the capabilities of the OIDC SSO, SCIM, or SAML module. The UserType
is now configured in the User Provisioning, which is integrated into the OIDC SSO, SCIM, and SAML modules. This means you can directly configure end-users of your application as Internal
or External
in the UserProvisioning tab of your app. Based on this configuration, users are updated each time they log in. These modules allow you to set the UserType
per IdP as the source of your end-users, assuming that separate IdPs are used for internal
and external
users.
For more information, refer to the User Provisioning section of the following modules:
Prerequisites for IdP-Based User Classification
-
Mendix and module versions:
- Mx9
- OIDC SSO: v3.0.0 or above
- SCIM: v1.0.0 or above
- Mx10
- OIDC SSO: v4.0.0 or above
- SAML: v4.0.0 or above
- SCIM: v2.0.0 or above
- Mx11
- OIDC SSO: v4.0.0 or above
- SAML: v4.0.0 or above
- SCIM: v2.0.0 or above
- Mx9
-
IdP Setup: Use separate IdPs for
Internal
andExternal
users.It may be possible to enhance configurations in your IdP by settting-up two separate connections between your app and your IdP. In this scenario, the IdP sees your app as two distinct clients/services. The Mendix app sees them as two distinct IdPs, each with its own provisioning configuration. This allows assigning differentUserType
values per IdP connection. Configurations in your IdP have to ensure that each client only addresses internal or external users. -
Classification on login: Classification of users happens when they log in. If your application has limited user buckets (for example, license restrictions for internal/external users), and timely classification is critical, ensure all (external) users log in before your limit on internal users is reached, as external users have not been classified as
External
users yet.
User Role-Based User Classification
Role-based classification relies on the distinct user roles defined within the application itself. This method is particularly effective for scenarios where an application needs to differentiate between user types, such as internal employees versus external users, by assigning them specific roles. Mendix offers the User Classification module, which aims to streamline the implementation of user role-based classification, thereby minimizing the development effort required within the application.
Instead of writing microflows, you can classify users as Internal
or External
using roles in the User Classification module. To do this:
- Define roles like
ExternalRole
or other custom roles. - Use the User Classification module to map these roles to the
UserType
field in theUserReportInfo
. - When a role is assigned to a user in your Mendix app, the User Classification module automatically updates the
UserType
field in theUserReportInfo
entity for that user.
This approach is simpler, more consistent, and easier to maintain than attribute-based logic.
For more information, see the Role-based Classification section of User Classification.
Prerequisites for Role-Based Classification
-
Your app model uses distinct user roles for external and internal users.
-
Include the User Classification module in your app model. To use it, your app must be running on one of the following Mendix versions:
- Mx9 LTS
- Mx10 LTS
- Mx11 and above
Custom Classification
When the logic of your application does not allow for IdP-based or user role-based user classification, you need to build your own custom user classification logic in your app. It lets you create specific rules tailored to the unique needs of your application.
Custom Classification Using the User Classification Module
This option lets you build custom logic while still using the framework from the User Classification module. It reduces development effort by giving you a structured way to add custom classification rules.
You can classify users as Internal
or External
using your own business rules instead of only user roles or IAM settings. With the User Classification module and a microflow, you can evaluate conditions, for example, email domain of end-users. The User Classification module makes it easy for you to implement custom logic to classify existing users as well as new users. This gives maximum flexibility to handle complex or unique scenarios and ensures accurate Mendix user metering. For more information, see the Custom Classification section of User Classification.
Custom Classification Using Your Own Microflow
For maximum control, developers can create user classification entirely from scratch using custom microflows. This gives full flexibility to define any classification rules and processes, making it the most customized approach.
UserType
attribute during initial end-user creation.
Outlined below is an example of a module that can be used to update the UserType
attribute. You will need to adapt the module logic for classifying your own internal and external end-users.
Domain Model
In the example below, our aim is to update the UserType
attribute of the UserReportInfo
entity. However, the entity UserReportInfo
is protected in the System module and has no access rules. As a result, it cannot be exposed directly in the UI pages.
Therefore, the approach we take is to create a new non-persistable entity, UserTypeReport
, which we will populate based on the values of UserReportInfo
to show in the UI.


Populating UserType
for Existing Users of an App
-
Create a microflow
User_RetrieveOrCreateUserReportInfo
which will ensure that aUserReportInfo
object exists for a givenUser
. -
Create a microflow
User_EvaluateAndSetUserType
which will populate theUserType
attribute on theUserReportInfo
entity for a givenUser
.In this example, we decide whether a user is
Internal
orExternal
based on the email address of the user. To do that, we need to retrieve the email address of each user from the database. Note that theSystem.User
entity itself does not have the email address. The email address is stored in the specializations ofSystem.User
.Here, we show how to do it for two specializations of the
System.User
entity, namelyAdministration.Account
andMendixSSO.MendixSSOUser
. In theAdministration.Account
entity, the email is in an attribute namedEmail
. And in theMendixSSO.MendixSSOUser
entity, it’s in an attribute namedEmailAddress
. Hence, we need to use an Object Type Decision activity to split theSystem.User
intoAdministration.Account
andMendixSSO.MendixSSOUser
and then fetch the email address according to the name of the attribute.-
The logic to determine whether the end-user is internal or external is up to the developer. The example below returns
true
, to indicate that the user is internal, if the user has no email address, or if the domain for their email address ismendix.com
ormyorg.com
.
-
-
Create a new microflow
User_Correct_UserType
which will use the microflowsUser_RetrieveOrCreateUserReportInfo
andUser_EvaluateAndSetUserType
created above. In this microflow, we create and populate theUserTypeReport
entity and return a list of these entities at the end of the microflow. -
Create a page
UserTypeReport
with a DataGrid which uses the microflowUser_Correct_UserType
as its source. -
Add the page to the Navigation.
-
When you go to that page, it will set the
UserType
as per your logic and show you the user type report. -
The report can be exported into an Excel file.