In your Mendix Pricing Plan there is a distinction between Internal and External Named Users of a Mendix App. This document helps you to set up your apps to meter External Users correctly. It describes a sample solution that can help you in External User classification for existing users of your apps.
- 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.
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. This attribute needs to be maintained for all existing and new end-users of a Mendix app. If this attribute is not set, the end-user is classified as an Internal User.
The Mendix Metering module relies on this attribute to ascertain the end-user type and report it back to us.
This approach is for end-users who are already set up in your app. For new end-users who onboard into your app, you can implement a similar logic to set the UserType attribute during initial end-user creation.
Outlined below is an example of a module that can be used to update UserType attribute. You will need to adapt the module logic for classifying your own internal and external end-users.
3.1 Domain model
In the example below, our aim is to update UserType attribute of 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.
3.2 Populating UserType for Existing Users of an App
Create a microflow
User_RetrieveOrCreateUserReportInfowhich will ensure that a
UserReportInfoobject exists for a given
Create a microflow
User_EvaluateAndSetUserTypewhich will populate the
UserTypeattribute on the
UserReportInfoentity for a given
In this example, we decide whether a user is
Externalbased 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 the
System.Userentity itself does not have the email address. The email address is stored in specializations of
Here, we show how to do it for two specializations of the
MendixSSO.MendixSSOUser. In the
Administration.Accountentity, the email is in attribute named
MendixSSO.MendixSSOUserentity, it’s in an attribute named
EmailAddress. Hence we need to use an Object Type Decision activity to split the
MendixSSO.MendixSSOUserand 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 is
Create a new microflow
User_Correct_UserTypewhich will use the microflows
User_EvaluateAndSetUserTypecreated above. In this microflow, we create and populate the
UserTypeReportentity and return a list of these entities at the end of the microflow.
Create a page
UserTypeReportwith a DataGrid which uses the microflow
User_Correct_UserTypeas its source.
Add the page to the Navigation.
When you go to that page it will set the
UserTypeas per your logic and show you the UserType report.
The report can be exported into an Excel file.