From 38d3f6322cd7d5155de019b6bba25681d041b981 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Mon, 23 Feb 2026 11:26:38 +0530 Subject: [PATCH 01/13] restructuring --- .../contract-management.md => contract-management/_index.md} | 0 .../_index.md => contract-management/licensing-apps.md} | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename content/en/docs/deployment/general/{licensing-apps/contract-management.md => contract-management/_index.md} (100%) rename content/en/docs/deployment/general/{licensing-apps/_index.md => contract-management/licensing-apps.md} (100%) diff --git a/content/en/docs/deployment/general/licensing-apps/contract-management.md b/content/en/docs/deployment/general/contract-management/_index.md similarity index 100% rename from content/en/docs/deployment/general/licensing-apps/contract-management.md rename to content/en/docs/deployment/general/contract-management/_index.md diff --git a/content/en/docs/deployment/general/licensing-apps/_index.md b/content/en/docs/deployment/general/contract-management/licensing-apps.md similarity index 100% rename from content/en/docs/deployment/general/licensing-apps/_index.md rename to content/en/docs/deployment/general/contract-management/licensing-apps.md From 3d04df3f93e553a8d30e565f9e732d7552160b0f Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Mon, 23 Feb 2026 12:05:29 +0530 Subject: [PATCH 02/13] moving populate user types --- .../general/{ => contract-management}/populate-user-type.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/en/docs/deployment/general/{ => contract-management}/populate-user-type.md (100%) diff --git a/content/en/docs/deployment/general/populate-user-type.md b/content/en/docs/deployment/general/contract-management/populate-user-type.md similarity index 100% rename from content/en/docs/deployment/general/populate-user-type.md rename to content/en/docs/deployment/general/contract-management/populate-user-type.md From 1db37f0dc93b4762d061bb31747c349cd32c94d9 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Mon, 23 Feb 2026 12:23:13 +0530 Subject: [PATCH 03/13] Add section - User Types and Definitions --- .../contract-management/licensing-apps.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/content/en/docs/deployment/general/contract-management/licensing-apps.md b/content/en/docs/deployment/general/contract-management/licensing-apps.md index 50dfd5c5bf9..be0d14da001 100644 --- a/content/en/docs/deployment/general/contract-management/licensing-apps.md +++ b/content/en/docs/deployment/general/contract-management/licensing-apps.md @@ -31,6 +31,25 @@ For each environment for which you want to remove the restrictions placed on an The app checks for a license each time it is started. If the license expires while the app is running, it will continue to run until the next time it is started, when the license will be checked again. +## User Types and Definitions + +Mendix licenses follow user-based pricing plans. This means customers pay based on how many users need access and what type of access they require for their Mendix applications. +Customers can purchase user licenses in the following categories: + +### Multi-App Internal User + +These are internal users (employee or contractor of the customer or affiliated company or group) who can access any number of applications, and are licensed under the Multi-app internal user pack. Each internal user is counted as one unique user, regardless of how many apps they access. + +### Single-App Internal User + +An internal user (employee or contractor) licensed for only one specific application and counted as one user limited to a single designated app. They are licensed under the Single-app internal user pack. + +### External User + +A user who is not an employee or contractor of the customer or its affiliates, and is explicitly marked “External” within your Mendix application data. This is one unique user across all apps designated for external use and licensed under the External user pack. + +For more information on legal definitions, refer to [Order Form Definitions](https://www.mendix.com/legal/platform-usage/order-form-definitions/). + ## Obtaining a Mendix License{#get-license} {{% alert color="info" %}} From f0c3b9bd9d737abd4e60df7764d55f4f39ec6021 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Mon, 23 Feb 2026 12:27:41 +0530 Subject: [PATCH 04/13] New page- User Metering --- .../general/contract-management/user-metering.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 content/en/docs/deployment/general/contract-management/user-metering.md diff --git a/content/en/docs/deployment/general/contract-management/user-metering.md b/content/en/docs/deployment/general/contract-management/user-metering.md new file mode 100644 index 00000000000..cba00194d5b --- /dev/null +++ b/content/en/docs/deployment/general/contract-management/user-metering.md @@ -0,0 +1,9 @@ +--- +title: "User Metering" +url: /developerportal/deploy/user-metering/ +weight: 20 +description: "This document describes how user metering works." +--- + +## Introduction + From e2c980b7d237b4583c5564d923d1b9864f33b105 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Mon, 23 Feb 2026 14:03:40 +0530 Subject: [PATCH 05/13] User metering overview page --- .../contract-management/user-metering.md | 73 +++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/content/en/docs/deployment/general/contract-management/user-metering.md b/content/en/docs/deployment/general/contract-management/user-metering.md index cba00194d5b..37fab20a103 100644 --- a/content/en/docs/deployment/general/contract-management/user-metering.md +++ b/content/en/docs/deployment/general/contract-management/user-metering.md @@ -7,3 +7,76 @@ description: "This document describes how user metering works." ## Introduction +End-user metering is the process Mendix uses to determine the number and type of users accessing applications in accordance with license agreements. Proper user classification ensures accurate reporting, optimal licensing costs, and transparency for both customers and Mendix. Customers can access usage reports through the Control Center application on the Mendix Platform. + +{{% alert color="info" %}} +End-user metering is currently available for applications deployed to Mendix Cloud and Mendix Cloud dedicated environments. +{{% /alert %}} + +Mendix licenses include user-based pricing plans. With user-based pricing, customers purchase licenses based on the number of users who need access to their Mendix applications. Customers can purchase user licenses in the following categories: + +* Multi-App Internal User +* Single-App Internal User +* External User + +For more information, refer to the [User Types and Definitions](/developerportal/deploy/licensing-apps-outside-mxcloud/#user-types-and-definitions) section of the *Licensing apps*. + +### Key Features + +* Automatic tracking – User consumption is automatically tracked from the moment your app is deployed to production and becomes functional, ensuring real-time tracking. +* Monthly reporting – Usage data is collected regularly, processed monthly, and is available in the Control Center. +* Application-level visibility – you get the detailed insights into named user counts for each application, helping you to identify optimization opportunities +* License type classification – Users are classified by license type as External, Multi-App Internal, or Single-App Internal. This classification gives you accurate license tracking and helps optimize licensing costs. +* Historical data – User metering provides you with access to usage data for all months since user metering was enabled. + +## How User Metering Works + +User metering in the Mendix cloud operates through a three-stage automated process, and it is enabled by default for apps deployed in Mendix cloud environments. + +### Data Collection + +Once users are classified as `internal` or `external`, all applications on the Mendix cloud and Mendix cloud dedicated automatically send user data back to the Mendix platform. The data is collected throughout the month only from the production environment. PII information (username and other user identifiers) is hashed at source before transmission to ensure data privacy. + +### Data Aggregation and Deduplication + +At the end of each month, the Mendix Platform aggregates the collected data. Users are counted and rolled up to the app portfolio level. This process is detailed in the [User Aggregation and Deduplication]() section below. + +### User Classification and Reporting + +Users are thereafter automatically classified in the following sequence: + +1. External Users +2. Single-App Users +3. Multi-App Internal Users (default) + +End-of-month usage reports are generated at the beginning of every month and made available via the Control Center dashboard. Reports are generally available on the 1st of each month for the previous month's usage. + +## How User Aggregation and Deduplication Work + +The user aggregation and deduplication process determines which user pack is consumed when a user accesses one or more of your applications. The process evaluates users in a sequence so that each user is counted according to the correct license pack without duplication. The classification follows the steps below: + +### Classifying External Users + +The first step is to determine whether a user is an external user: + +* If the customer has a valid External User Pack subscription, and +* The user is explicitly marked as "External" within the application + +Then the User is classified as an External User. + +Once classified, the user is licensed under the External User Pack and excluded from further classification steps. For more information, see the [User classification]() section of *Implementing Metering*. + +All remaining users are classified as internal Users and further classified as described in the sections below. + +### Classifying Single-App Internal Users + +After external users are classified, the classification process further classifies the single-app internal users. + +If the application is associated with a Single-App Internal User Pack, the user of the app will be classified as a single-app internal user. This user will be counted against the single-app internal user pack for that application. + +For more details on how to assign single-app user packs to your apps, refer to the [Assigning Single-App Internal User Packs](to be linked) section of the Control Center. + +### Classifying Multi-App Internal Users + +After external users and single-app internal users have been identified, any remaining internal users are classified as multi-app internal users. +These users are licensed under the multi-app internal user pack, and no further action is required from your side. From 5e98588ecd8ed97bf053a379dbc06bc3291e8417 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Mon, 23 Feb 2026 16:01:39 +0530 Subject: [PATCH 06/13] Creating user metering category --- .../{user-metering.md => user-metering/_index.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/en/docs/deployment/general/contract-management/{user-metering.md => user-metering/_index.md} (100%) diff --git a/content/en/docs/deployment/general/contract-management/user-metering.md b/content/en/docs/deployment/general/contract-management/user-metering/_index.md similarity index 100% rename from content/en/docs/deployment/general/contract-management/user-metering.md rename to content/en/docs/deployment/general/contract-management/user-metering/_index.md From 866b3c34787a0403596ceff6008bd651033b3097 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Mon, 23 Feb 2026 16:06:59 +0530 Subject: [PATCH 07/13] new page- implementing user metering --- .../user-metering/implementing-user-metering.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md diff --git a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md new file mode 100644 index 00000000000..e283682df36 --- /dev/null +++ b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md @@ -0,0 +1,9 @@ +--- +title: "Implementing User Metering" +url: /developerportal/deploy/user-metering/ +weight: 20 +description: "This document describes how to implement user metering." +--- + +## Introduction + From 6cf8a53e27b5d8dcc34d504fe1c576b4d75fe075 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Mon, 23 Feb 2026 16:51:39 +0530 Subject: [PATCH 08/13] implementing user metering info --- .../implementing-user-metering.md | 72 ++++++++++++++++++- 1 file changed, 71 insertions(+), 1 deletion(-) diff --git a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md index e283682df36..15c02b8e7d2 100644 --- a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md +++ b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md @@ -1,9 +1,79 @@ --- title: "Implementing User Metering" url: /developerportal/deploy/user-metering/ -weight: 20 +weight: 40 description: "This document describes how to implement user metering." --- ## Introduction +User metering provides complete visibility into the number and types of users accessing the application, ensuring compliance with the license agreement. You can see this data in the Usage Report of Control Center on the Mendix platform. +For accurate user metering, you need in-app user classification as a first step. For more information, refer to [How User Metering Works](developerportal/deploy/user-metering/#how-user-metering-works). To do this, the logic in your app models needs to cater to the following aspects, if applicable: + +* Unique user identification +* User classification +* User deactivation + +## Guidelines for Unique User Identification (Deduplication) + +Mendix allows you to build multi-app solutions and offers a multi-app user license option. For internal users, you may have a single-app user license or a multi-app user license. External user licenses cover both single-app and multi-app users; a multi-app external user is counted only once. For more information, refer to [User types and definitions](/developerportal/deploy/licensing-apps-outside-mxcloud/#user-types-and-definitions). For accurate user metering, it is a crucial step to identify the unique multi-app user by using the same user identifier in all apps for a user. + +The Mendix metering mechanism requires your app logic to store an identifier for every user in the `UserCommons.namedUserIdentifier.value` (or `system.user.name` as a fallback). For relevant entities and their attributes, see the [Domain Model Entities]() section below. + +For metering of multi-app users, the same value must be stored across all apps. When different values have persisted, Mendix sees them as different users. + +To ensure your multi-app users are counted correctly, you may want to consider the following guidelines: + +### Choosing a cross-app user identifier + +User metering may not have been considered when your application was originally designed. As a result, different applications may store different identifier values for the same multi-app user in the `system.user.name`. Additionally, all apps in your portfolio may use different user-provisioning logic. Some apps use standard identity modules (Administration, SAML, OIDC SSO, SCIM, or LDAP module) while others rely on proprietary modules or app logic to create users. This can lead to inconsistent identifiers. +Even when all apps use the same solution, for example, OIDC SSO, the technical identifier value for a multi-app user may still differ. + +### Avoiding pairwise identifiers: + +Even if all your apps are using the same user onboarding (provisioning) logic, this does not guarantee a user gets the same (technical) identifier value in all your applications. +The OpenID Connect specifications incorporate the concept of [pairwise user identifiers](https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg). The general idea of pairwise identifiers is to prevent user correlation across apps owned by different service providers. A user gets a different value in each app when using pairwise user identifiers. + +Mendix recommends storing the user’s email address in the `UserCommons.NamedUserIdentifier.value`; this ensures usage of a pairwise unique identifier in the `system.user.name` does not affect metering. + +Within your application portfolio, the possibility to prevent cross-app user correlation is probably not needed; instead, you do want the Mendix metering system to correlate users and recognize multi-app users. Microsoft’s Entra ID uses pairwise identifiers in the OIDC `sub` claim. It is, however, possible to include the `oid` claim, which contains the same value for a given multi-app user across all applications; Entra ID’s `object-id`. Mendix recommends storing the `oid` claim in the `system.user.name` if you are using the OIDC SSO module with Entra ID. + +### Keeping the Existing Logic and Extending + +If your apps are not consistently storing the same identifier for a multi-app user in `system.user.name`, you can start using a new user attribute, new `UserCommons.namedUserIdentifier.value`.You can keep the existing application logic as it is, and in addition, store the selected user identifier value for a multi-app user in this new attribute. + +### Paying Attention to Case Sensitivity + +By design, the `system.user.name` is case sensitive and allows customers to store any user identifier without restrictions. If you choose to store an email address in these fields, or another identifier, that should be treated as case-insensitive. Mendix recommends downcasting such values to lowercase. The SAML, OIDC SSO, and SCIM modules already apply this for email claims/attributes received from your IdP. + +For more information, refer to the [Versioning]() section below. + +## User Classification + +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. +There are several approaches to classify users as `Internal` or `External`, ranging from configuration-only to custom development. These options are: + +### IdP-Based User Classification + +This method requires one of the following identity modules to be enabled: OIDC SSO, SCIM, or SAML. A key advantage of this approach is that it does not require any modifications to your existing app. Classification can begin immediately by setting a constant. However, because users are only classified when they log in, it may take some time before all end users are classified. + +For more information, see the [IdP-Based User Classification](/developerportal/deploy/populate-user-type/#idp-based-user-classification) section of *Populate User Types*. + +### Userrole-Based User Classification + +The user-role-based user classification module classifies users by using the roles already defined in your app. It can update all existing users in one run and works well if you already have separate roles for internal and external users. However, using this module requires upgrading your app to include the user classification module. For more information, refer to [User-Role-Based Classification](developerportal/deploy/populate-user-type/#user-role-based-user-classification). + +### Custom User Classification + +This method can be implemented either by using the [User Classification](/appstore/modules/user-classification/) module or by creating fully custom microflows. The main advantage of this approach is the flexibility it provides- you can apply any classification logic you choose while still relying on the user classification module as the base. However, this method requires developing custom logic and involves upgrading your app to a new version of your app to include the [user classification](https://marketplace.mendix.com/link/component/245015) module. + +{{% alert color="info" %}} +In situations where there is ambiguity about the user classification, Mendix considers users as internal users. Ambiguity may happen in the following situations: + +* A multi-app user is marked as external in one app and internal in another app. +* When applying userrole-based classification, and a user has both an Internal and an External userrole. +{{% /alert %}} + +Classification by the platform is not supported by using your email domains, nor any other logic. Your app logic is responsible for classification. For more information, refer to [Custom Classification](/developerportal/deploy/populate-user-type/#custom-classification). + +## (De)Activation of users \ No newline at end of file From 884ccade9a12e8d22470da8035c39c67130d22c4 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Mon, 23 Feb 2026 17:04:04 +0530 Subject: [PATCH 09/13] (De)Activation of users --- .../implementing-user-metering.md | 21 ++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md index 15c02b8e7d2..bd45f66e6bd 100644 --- a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md +++ b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md @@ -76,4 +76,23 @@ In situations where there is ambiguity about the user classification, Mendix con Classification by the platform is not supported by using your email domains, nor any other logic. Your app logic is responsible for classification. For more information, refer to [Custom Classification](/developerportal/deploy/populate-user-type/#custom-classification). -## (De)Activation of users \ No newline at end of file +## (De)Activation of users + +`system.user.active` attribute controls active or inactive users in your application. Users with an ‘active’ state can log in to your app and are counted for user metering purposes, while non-active users cannot login are not counted for user metering. + +You can provision the user records (for example, created, updated, or deleted) using proprietary logic or via one of the following platforms supported modules: + +* SAML and OIDC SSO modules can create users with active state. By nature of the SSO protocols, these modules do not deactivate or delete any user records in your application. +* The SCIM module allows your app to be integrated with your IdP to create, update, or delete user records. Depending on the (configured) business logic in your IdP, users may be created, deactivated, or deleted + + * as a result of the Joiner/Mover/Leaver processes. + * as result of license optimization, users who haven’t logged in to a certain application for a certain period may be removed from the access group in the IdP, and therefore, the IdP may deactivate or remove users from your SCIM-enabled application. + +* The LDAP module allows you to synchronize users and their status (active=false/true) from your on-premises Active Directory to your application. This is a similar module to SCIM but using a different protocol. + +If you are considering deactivating or removing user records for optimization of user cost, you are advised to consider the following: + +* Users cannot log in when in the deactivated (active=false) state. The primary purpose of the active state is to control which users can log in. When SSO is used, the user may be successfully logged in at the IdP; however, the Mendix application fails to grant access if the active state is not updated. +* Actual logins, frequency of login, or system.user.lastlogin is also not relevant for metering. A user is counted as an active user if the state was active on any day of the calendar month. +* If you choose to remove user records, associated data may be deleted depending on your domain model. +* The SAML and OIDC SSO modules are capable of (re)creating any user that was deleted. This can be described as just-in-time user provisioning, also known as on-the-fly user onboarding or real-time user creation. \ No newline at end of file From 616cb47c4579c117c5a84a0d4ae3e10a53cdd0ef Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Tue, 24 Feb 2026 11:28:58 +0530 Subject: [PATCH 10/13] Additional info --- .../implementing-user-metering.md | 56 +++++++++++++++---- 1 file changed, 46 insertions(+), 10 deletions(-) diff --git a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md index bd45f66e6bd..fdabcd5a009 100644 --- a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md +++ b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md @@ -1,6 +1,6 @@ --- title: "Implementing User Metering" -url: /developerportal/deploy/user-metering/ +url: /developerportal/deploy/implementing-user-metering/ weight: 40 description: "This document describes how to implement user metering." --- @@ -8,25 +8,25 @@ description: "This document describes how to implement user metering." ## Introduction User metering provides complete visibility into the number and types of users accessing the application, ensuring compliance with the license agreement. You can see this data in the Usage Report of Control Center on the Mendix platform. -For accurate user metering, you need in-app user classification as a first step. For more information, refer to [How User Metering Works](developerportal/deploy/user-metering/#how-user-metering-works). To do this, the logic in your app models needs to cater to the following aspects, if applicable: +For accurate user metering, in-app user classification is a crucial first step. For more information, refer to [How User Metering Works](developerportal/deploy/user-metering/#how-user-metering-works). To do this, the logic in your app models needs to cater to the following aspects, if applicable: -* Unique user identification -* User classification -* User deactivation +* [Unique user identification](/developerportal/deploy/implementing-user-metering/#guidelines-for-unique-user-identification-deduplication) +* [User classification](/developerportal/deploy/implementing-user-metering/#user-classification) +* [User deactivation](/developerportal/deploy/implementing-user-metering/#deactivation-of-users) ## Guidelines for Unique User Identification (Deduplication) Mendix allows you to build multi-app solutions and offers a multi-app user license option. For internal users, you may have a single-app user license or a multi-app user license. External user licenses cover both single-app and multi-app users; a multi-app external user is counted only once. For more information, refer to [User types and definitions](/developerportal/deploy/licensing-apps-outside-mxcloud/#user-types-and-definitions). For accurate user metering, it is a crucial step to identify the unique multi-app user by using the same user identifier in all apps for a user. -The Mendix metering mechanism requires your app logic to store an identifier for every user in the `UserCommons.namedUserIdentifier.value` (or `system.user.name` as a fallback). For relevant entities and their attributes, see the [Domain Model Entities]() section below. +The Mendix metering mechanism requires your app logic to store an identifier for every user in the `UserCommons.namedUserIdentifier.value` (or `system.user.name` as a fallback). For relevant entities and their attributes, see the [Domain Model Entities](/developerportal/deploy/implementing-user-metering/#domain-model-entities) section below. -For metering of multi-app users, the same value must be stored across all apps. When different values have persisted, Mendix sees them as different users. +For metering of multi-app users, the same value must be stored across all apps. When different values persist, Mendix treats them as different users. To ensure your multi-app users are counted correctly, you may want to consider the following guidelines: ### Choosing a cross-app user identifier -User metering may not have been considered when your application was originally designed. As a result, different applications may store different identifier values for the same multi-app user in the `system.user.name`. Additionally, all apps in your portfolio may use different user-provisioning logic. Some apps use standard identity modules (Administration, SAML, OIDC SSO, SCIM, or LDAP module) while others rely on proprietary modules or app logic to create users. This can lead to inconsistent identifiers. +User metering may not have been considered when your application was originally designed. As a result, different applications may store different identifier values for the same multi-app user in the `system.user.name`. Additionally, all apps in your portfolio may use different user-provisioning logic. Some apps use standard identity modules (Administration, SAML, OIDC SSO, SCIM, or LDAP) while others rely on proprietary modules or app logic to create users. This can lead to inconsistent identifiers. Even when all apps use the same solution, for example, OIDC SSO, the technical identifier value for a multi-app user may still differ. ### Avoiding pairwise identifiers: @@ -46,7 +46,7 @@ If your apps are not consistently storing the same identifier for a multi-app us By design, the `system.user.name` is case sensitive and allows customers to store any user identifier without restrictions. If you choose to store an email address in these fields, or another identifier, that should be treated as case-insensitive. Mendix recommends downcasting such values to lowercase. The SAML, OIDC SSO, and SCIM modules already apply this for email claims/attributes received from your IdP. -For more information, refer to the [Versioning]() section below. +For more information, refer to the [Versioning](/developerportal/deploy/implementing-user-metering/#versioning-information) section below. ## User Classification @@ -95,4 +95,40 @@ If you are considering deactivating or removing user records for optimization of * Users cannot log in when in the deactivated (active=false) state. The primary purpose of the active state is to control which users can log in. When SSO is used, the user may be successfully logged in at the IdP; however, the Mendix application fails to grant access if the active state is not updated. * Actual logins, frequency of login, or system.user.lastlogin is also not relevant for metering. A user is counted as an active user if the state was active on any day of the calendar month. * If you choose to remove user records, associated data may be deleted depending on your domain model. -* The SAML and OIDC SSO modules are capable of (re)creating any user that was deleted. This can be described as just-in-time user provisioning, also known as on-the-fly user onboarding or real-time user creation. \ No newline at end of file +* The SAML and OIDC SSO modules are capable of (re)creating any user that was deleted. This can be described as just-in-time user provisioning, also known as on-the-fly user onboarding or real-time user creation. + +## Versioning Information + +The improved user metering capabilities are introduced in Mendix 11. These capabilities in the platform apply to apps using any Mendix version. Mendix offers the following guidance on versioning. + +| Classification Menthod | Mendix 9 LTS | Mendix 10 LTS, Mendix 11 | +| --- | --- | --- | +| IdP-based user classification | SAML 3.6.21 and above
OIDC 3.0.0 and above | SAML 4.0.0 and above
OIDC SSO v4.0.0 and above | +| Userrole-based or custom user classification | User Classification v1.0.1 and above | User Classification v2.0.0 and above | +| Multi-app user identification | `system.user.name` | `system.user.name` or `NamedUserIdentifier` in User Commons v2.2.0 and above | +| SCIM-based user deactivation | SCIM v3.0.0 and above | SCIM v4.0.0 and above | + +If you have extended support on Mendix 8, contact your CSM for guidance on user metering if needed. + +## Domain Model Entities + +This section explains the entities and their attributes in your app domain model that are relevant for user metering. + +The following are entities and their attributes: + +1. `User`: Every Mendix app has a system module containing an entity `User`. + + * `system.user.name`: This field is used to identify users, unless a UserCommons.namedUserIdentifier.value is available for the same user. + * `system.User.Active`: A Boolean attribute, `Active`, is used to select the active user account for user metering. A user record that has `Active=true` during the metering period is counted as an active user during the billing period and reconciliated against one of the allocated user licenses. + +2. `UserReportInfo`: The system module also features the `UserReportInfo`. + + * `system.UserReportInfo.UserType`: `UserType` 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`. + +3. `namedUserIdentifier`(optional): Recent versions of the [UserCommons](https://marketplace.mendix.com/link/component/223053) module include a `namedUserIdentifier` entity. + + * `UserCommons.namedUserIdentifier.value`: User commons modules in your app model assign the values to the `namedUserIdentifier.value` attribute to identify a user instead of `system.user.name`.The `namedUserIdentifier` overrides `user.name`. + +Note that one application may use `system.user.name` and not `userCommons.namedUserIdentifier.value`, or may exclude the UserCommons module, while another application may use `userCommons.namedUserIdentifier.value` instead. If the values in these different fields are the same for a multi-app user, the Mendix user metering mechanism correctly identifies the user as a single multi-app user (deduplication). + +It is not possible to map multiple values of `system.user.name` to a single value of `UserCommons.namedUserIdentifier.value` within an app. From 0ee9b29ac87d81457c62a6050ce51055a089aa20 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Tue, 24 Feb 2026 11:43:05 +0530 Subject: [PATCH 11/13] new page- FAQ --- .../deployment/general/contract-management/_index.md | 2 +- .../general/contract-management/user-metering/faq.md | 11 +++++++++++ .../user-metering/implementing-user-metering.md | 2 +- 3 files changed, 13 insertions(+), 2 deletions(-) create mode 100644 content/en/docs/deployment/general/contract-management/user-metering/faq.md diff --git a/content/en/docs/deployment/general/contract-management/_index.md b/content/en/docs/deployment/general/contract-management/_index.md index 35634ad851d..ee06b6e48e8 100644 --- a/content/en/docs/deployment/general/contract-management/_index.md +++ b/content/en/docs/deployment/general/contract-management/_index.md @@ -1,7 +1,7 @@ --- title: "Contract Management" url: /developerportal/deploy/contract-management/ -weight: 20 +weight: 10 description: "Understand your Mendix subscription lifecycle, contract statuses, renewal timelines, and critical actions to ensure continuous service and prevent data loss." --- diff --git a/content/en/docs/deployment/general/contract-management/user-metering/faq.md b/content/en/docs/deployment/general/contract-management/user-metering/faq.md new file mode 100644 index 00000000000..97c4bfadde4 --- /dev/null +++ b/content/en/docs/deployment/general/contract-management/user-metering/faq.md @@ -0,0 +1,11 @@ +--- +title: "Frequently Asked Questions on User Metering" +linktitle: FAQs on User Metering +url: /developerportal/deploy/faq/ +weight: 40 +description: "This document contains a list of frequently asked questions on user metering." +--- + +## Introduction + +This document answers common questions about user metering, outlining user classification and users. diff --git a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md index fdabcd5a009..75045a3412b 100644 --- a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md +++ b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md @@ -1,7 +1,7 @@ --- title: "Implementing User Metering" url: /developerportal/deploy/implementing-user-metering/ -weight: 40 +weight: 30 description: "This document describes how to implement user metering." --- From 44b720c12d3dd96e4646b26ccc1583dc7fe365f0 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Tue, 24 Feb 2026 16:35:46 +0530 Subject: [PATCH 12/13] Proofreading --- .../general/contract-management/_index.md | 6 +- .../user-metering/_index.md | 10 +- .../contract-management/user-metering/faq.md | 97 +++++++++++++++++++ 3 files changed, 105 insertions(+), 8 deletions(-) diff --git a/content/en/docs/deployment/general/contract-management/_index.md b/content/en/docs/deployment/general/contract-management/_index.md index ee06b6e48e8..e3ce221f699 100644 --- a/content/en/docs/deployment/general/contract-management/_index.md +++ b/content/en/docs/deployment/general/contract-management/_index.md @@ -16,7 +16,7 @@ This document provides detailed information about the status of your Mendix appl Your Mendix subscription is categorized into three main statuses: Active, Expiring, and Expired, based on your contract's expiry date. | Account Status | Timeline | Impact | -|---------------|----------|--------------------| +| --------------- | ---------- | -------------------- | | **Active (Green)** | Until 30 days before contract expiry | Your account is fully active, with all services available and application runtimes functioning normally. This is the optimal state for uninterrupted Mendix usage. | | **Expiring (Orange)** | From 30 days before contract expiry until contract end date | All services continue to function normally. You receive email reminders, notifications, and banner alerts on Mendix Platform about your upcoming renewal. | | **Expired (Red)** | From the day after contract expiry up to 60 days | Your account and applications are downgraded to **Unlicensed** mode. You can manually restart apps, but they will automatically shut down after 2-4 hours and are limited to 6 concurrent users. Platform features are not disabled.| @@ -68,7 +68,7 @@ This is your final opportunity to renew your contract and avoid service disrupti #### Pre-Expiry Timeline Summary{#pre-expiry-timeline-summary} | **Days Before Expiry** | **Key Actions** | **Status** | -|------------------------|-----------------|------------| +| ------------------------ | ----------------- | ------------ | | **90 days** | Contact Account Team for renewal | Active | | **30 days** | Finalize renewal discussions | Expiring | | **15 days** | Download data if not renewing | Expiring | @@ -95,7 +95,7 @@ Application data deletion is irreversible. Make sure to download all necessary a #### Post-Expiry Timeline Summary{#post-expiry-timeline-summary} | **Days After Expiry** | **Key Actions** | **Status** | -|------------------------|-----------------|------------| +| ------------------------ | ----------------- | ------------ | | **0 days (Expired)** | Contract expires | Expired | | **+1 day** | Limited access | Expired | | **+60 days** | Data permanently deleted | Expired | diff --git a/content/en/docs/deployment/general/contract-management/user-metering/_index.md b/content/en/docs/deployment/general/contract-management/user-metering/_index.md index 37fab20a103..07fb4e0fa36 100644 --- a/content/en/docs/deployment/general/contract-management/user-metering/_index.md +++ b/content/en/docs/deployment/general/contract-management/user-metering/_index.md @@ -7,10 +7,10 @@ description: "This document describes how user metering works." ## Introduction -End-user metering is the process Mendix uses to determine the number and type of users accessing applications in accordance with license agreements. Proper user classification ensures accurate reporting, optimal licensing costs, and transparency for both customers and Mendix. Customers can access usage reports through the Control Center application on the Mendix Platform. +End-user metering is the process Mendix uses to determine the number and type of users accessing applications in accordance with license agreements. Proper user classification ensures accurate reporting, optimal licensing costs, and transparency for both customers and Mendix. Customers can access Usage Report through the Control Center application on the Mendix Platform. {{% alert color="info" %}} -End-user metering is currently available for applications deployed to Mendix Cloud and Mendix Cloud dedicated environments. +End-user metering is currently available for applications deployed to Mendix Cloud and Mendix Cloud Dedicated environments. {{% /alert %}} Mendix licenses include user-based pricing plans. With user-based pricing, customers purchase licenses based on the number of users who need access to their Mendix applications. Customers can purchase user licenses in the following categories: @@ -35,11 +35,11 @@ User metering in the Mendix cloud operates through a three-stage automated proce ### Data Collection -Once users are classified as `internal` or `external`, all applications on the Mendix cloud and Mendix cloud dedicated automatically send user data back to the Mendix platform. The data is collected throughout the month only from the production environment. PII information (username and other user identifiers) is hashed at source before transmission to ensure data privacy. +Once users are classified as `internal` or `external`, all applications on the Mendix Cloud and Mendix Cloud Dedicated automatically send user data back to the Mendix platform. The data is collected throughout the month only from the production environment. PII information (username and other user identifiers) is hashed at source before transmission to ensure data privacy. ### Data Aggregation and Deduplication -At the end of each month, the Mendix Platform aggregates the collected data. Users are counted and rolled up to the app portfolio level. This process is detailed in the [User Aggregation and Deduplication]() section below. +At the end of each month, the Mendix Platform aggregates the collected data. Users are counted and rolled up to the app portfolio level. This process is detailed in the [User Aggregation and Deduplication](/developerportal/deploy/user-metering/#how-user-aggregation-and-deduplication-work) section below. ### User Classification and Reporting @@ -64,7 +64,7 @@ The first step is to determine whether a user is an external user: Then the User is classified as an External User. -Once classified, the user is licensed under the External User Pack and excluded from further classification steps. For more information, see the [User classification]() section of *Implementing Metering*. +Once classified, the user is licensed under the External User Pack and excluded from further classification steps. For more information, see the [User classification](/developerportal/deploy/implementing-user-metering/#user-classification) section of *Implementing Metering*. All remaining users are classified as internal Users and further classified as described in the sections below. diff --git a/content/en/docs/deployment/general/contract-management/user-metering/faq.md b/content/en/docs/deployment/general/contract-management/user-metering/faq.md index 97c4bfadde4..48f7e55d64a 100644 --- a/content/en/docs/deployment/general/contract-management/user-metering/faq.md +++ b/content/en/docs/deployment/general/contract-management/user-metering/faq.md @@ -9,3 +9,100 @@ description: "This document contains a list of frequently asked questions on use ## Introduction This document answers common questions about user metering, outlining user classification and users. + +## General Questions + +### Is User Metering Automatically Enabled? + +User metering is automatically enabled for all Mendix Cloud and Mendix Cloud Dedicated applications without requiring any configuration or setup for usage data collection. Data collection begins as soon as your application is deployed to a production environment. + +### Where Can I View My User Consumption Data? + +Navigate to the **Control Center** > **Entitlements** > **End-Users** > **Usage Report**. +For more information, refer to the Usage Report Tab section of *End-Users*. + +### When Can I See My Monthly Usage Data? + +User pack utilization is extracted regularly from the apps and available as a daily snapshot on the Control Center. +The daily snapshots are processed and deduplicated across all your apps at the end of each month and become available on the 1st of the following month as monthly usage data. Monthly reports show aggregated license usage over the month. + +### What Happens if I Exceed My Entitlement? + +If you exceed your licensed entitlements: + +* No immediate service disruption: Your applications continue to run normally. +* Alert displayed: A warning icon appears in the end-of-month Usage Report on the Control Center. +* Compliance discussion: Your Customer Success Manager (CSM) will contact you to discuss: + + * Purchasing additional user packs + * Optimizing user classification + * Adjusting your license agreement + +Mendix recommends that you monitor your usage regularly and purchase additional capacity before reaching your limit. + +### Can I View Usage Data From Previous Months? + +Apps across Mendix Cloud began collecting user metering data starting in November 2025. Based on when your app was onboarded on user metering, you may have access to historical usage data. Navigate to the **Usage Report** and select the desired month to see the usage data. + +## Questions on User Classification + +### How Are Users Classified If I Do Not Configure User Classification? + +If no action is taken, all users are classified as Multi-App Internal Users by default. +This means all users in your apps are aggregated together and classified as multi-app internal users. + +### I Have External Users in My Applications. How Do I Ensure They Are Counted Correctly? + +Explicitly mark users as `External` in your application to ensure they are counted correctly under your External User pack. If you do not have an External User pack, these users will be classified as `Internal`, even if they are marked as `External` users. + +For more information, refer to [User Classification](/developerportal/deploy/implementing-user-metering/#user-classification). + +### I Purchased a Single-App User Pack for My Application. How Do I Set It Up? + +Assign the Single-App User Pack to your application in the Control Center. For more information, refer to Assigning Single-App Internal User Packs. + +### How Do I Assign Single-App User Packs to Multiple Applications With Unique User Bases? + +You must purchase a separate Single-App User Pack for each application and assign them individually. Contact your CSM or account team to purchase additional packs. + +## User-Specific Questions + +### How Are Users Counted If They Log In Only Once Per Year? + +Users are counted based on their active status, not login frequency. If they are marked as `Active` in your application, they are counted every month, regardless of whether they log in. + +Note that if the user has active status during any moment in a month, they are counted as active user for that calendar month. + +### What Is the Best Practice for Deactivating Users Who Left the Organization? + +Deactivate users as soon as they no longer need access. This ensures that they are not counted in future usage reports and helps maintain security. Deactivate leavers before month-end to optimize license consumption. + +### Should I Delete or Deactivate Users To Save on License Costs? + +Technically, you can deactivate or remove users to optimize license costs. + +To optimise license cost, you may choose to delete records in the `system.user` object, while maintaining data in custom user objects. + +{{% alert color="info" %}} +Check your organization's data retention policies before purging any user data. Deactivation usually satisfies both license optimization and compliance requirements. +{{% /alert %}} + +### Are Anonymous Users Counted in User Metering? + +Anonymous Users are users who access your application without logging in or authenticating. Anonymous Users are not counted in user metering. Only Named Users (users with unique login credentials) are counted. + +### Are API Users and Service Accounts Counted in User Metering? + +API Users (also called Service Accounts or System Users) are non-human accounts used for: + +* System-to-system integrations +* Automated processes +* Background jobs +* External system access via web services + +API users with authentication count as Named Users and are included in user metering. + +## Read More + +* [User Metering](/developerportal/deploy/user-metering/) +* [Implementing User Metering](/developerportal/deploy/implementing-user-metering/) \ No newline at end of file From 492a5da4a57cc239958e373324a62d2f91abaf98 Mon Sep 17 00:00:00 2001 From: Karuna-Mendix Date: Wed, 25 Feb 2026 12:24:47 +0530 Subject: [PATCH 13/13] Proofreading --- .../user-metering/_index.md | 24 +++++++++++-------- .../implementing-user-metering.md | 24 +++++++++---------- 2 files changed, 26 insertions(+), 22 deletions(-) diff --git a/content/en/docs/deployment/general/contract-management/user-metering/_index.md b/content/en/docs/deployment/general/contract-management/user-metering/_index.md index 07fb4e0fa36..4d135f31583 100644 --- a/content/en/docs/deployment/general/contract-management/user-metering/_index.md +++ b/content/en/docs/deployment/general/contract-management/user-metering/_index.md @@ -19,23 +19,23 @@ Mendix licenses include user-based pricing plans. With user-based pricing, custo * Single-App Internal User * External User -For more information, refer to the [User Types and Definitions](/developerportal/deploy/licensing-apps-outside-mxcloud/#user-types-and-definitions) section of the *Licensing apps*. +For more information, refer to the [User Types and Definitions](/developerportal/deploy/licensing-apps-outside-mxcloud/#user-types-and-definitions) section of *Licensing apps*. ### Key Features * Automatic tracking – User consumption is automatically tracked from the moment your app is deployed to production and becomes functional, ensuring real-time tracking. * Monthly reporting – Usage data is collected regularly, processed monthly, and is available in the Control Center. -* Application-level visibility – you get the detailed insights into named user counts for each application, helping you to identify optimization opportunities +* Application-level visibility – you get the detailed insights into named user counts for each application, helping you to identify optimization opportunities. * License type classification – Users are classified by license type as External, Multi-App Internal, or Single-App Internal. This classification gives you accurate license tracking and helps optimize licensing costs. * Historical data – User metering provides you with access to usage data for all months since user metering was enabled. ## How User Metering Works -User metering in the Mendix cloud operates through a three-stage automated process, and it is enabled by default for apps deployed in Mendix cloud environments. +User metering in the Mendix cloud operates through a three-stage automated process, and it is enabled by default for apps deployed in Mendix Cloud environments. ### Data Collection -Once users are classified as `internal` or `external`, all applications on the Mendix Cloud and Mendix Cloud Dedicated automatically send user data back to the Mendix platform. The data is collected throughout the month only from the production environment. PII information (username and other user identifiers) is hashed at source before transmission to ensure data privacy. +Once users are classified as `Internal` or `External`, all applications on the Mendix Cloud and Mendix Cloud Dedicated automatically send user data back to the Mendix platform. The data is collected throughout the month from the production environment only. PII information (username and other user identifiers) is hashed at source before transmission to ensure data privacy. ### Data Aggregation and Deduplication @@ -49,7 +49,7 @@ Users are thereafter automatically classified in the following sequence: 2. Single-App Users 3. Multi-App Internal Users (default) -End-of-month usage reports are generated at the beginning of every month and made available via the Control Center dashboard. Reports are generally available on the 1st of each month for the previous month's usage. +End-of-month usage reports are generated at the beginning of each month and are made available via the Control Center dashboard. The reports are generally available on the 1st of each month and reflect the previous month's usage. ## How User Aggregation and Deduplication Work @@ -60,23 +60,27 @@ The user aggregation and deduplication process determines which user pack is con The first step is to determine whether a user is an external user: * If the customer has a valid External User Pack subscription, and -* The user is explicitly marked as "External" within the application +* The user is explicitly marked as `External` within the application. -Then the User is classified as an External User. +Then the User is classified as an External user. Once classified, the user is licensed under the External User Pack and excluded from further classification steps. For more information, see the [User classification](/developerportal/deploy/implementing-user-metering/#user-classification) section of *Implementing Metering*. -All remaining users are classified as internal Users and further classified as described in the sections below. +All remaining users are classified as `Internal` Users and further classified as described in the sections below. ### Classifying Single-App Internal Users -After external users are classified, the classification process further classifies the single-app internal users. +After `External` users are classified, the classification process further classifies the single-app internal users. If the application is associated with a Single-App Internal User Pack, the user of the app will be classified as a single-app internal user. This user will be counted against the single-app internal user pack for that application. -For more details on how to assign single-app user packs to your apps, refer to the [Assigning Single-App Internal User Packs](to be linked) section of the Control Center. +For more details on how to assign single-app user packs to your apps, refer to the Assigning Single-App Internal User Packs section of the Control Center. ### Classifying Multi-App Internal Users After external users and single-app internal users have been identified, any remaining internal users are classified as multi-app internal users. These users are licensed under the multi-app internal user pack, and no further action is required from your side. + +## Read More + +* [Licensing Apps](developerportal/deploy/licensing-apps-outside-mxcloud/) diff --git a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md index 75045a3412b..fc444285728 100644 --- a/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md +++ b/content/en/docs/deployment/general/contract-management/user-metering/implementing-user-metering.md @@ -24,12 +24,12 @@ For metering of multi-app users, the same value must be stored across all apps. To ensure your multi-app users are counted correctly, you may want to consider the following guidelines: -### Choosing a cross-app user identifier +### Choosing a Cross-App User Identifier: User metering may not have been considered when your application was originally designed. As a result, different applications may store different identifier values for the same multi-app user in the `system.user.name`. Additionally, all apps in your portfolio may use different user-provisioning logic. Some apps use standard identity modules (Administration, SAML, OIDC SSO, SCIM, or LDAP) while others rely on proprietary modules or app logic to create users. This can lead to inconsistent identifiers. Even when all apps use the same solution, for example, OIDC SSO, the technical identifier value for a multi-app user may still differ. -### Avoiding pairwise identifiers: +### Avoiding Pairwise Identifiers: Even if all your apps are using the same user onboarding (provisioning) logic, this does not guarantee a user gets the same (technical) identifier value in all your applications. The OpenID Connect specifications incorporate the concept of [pairwise user identifiers](https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg). The general idea of pairwise identifiers is to prevent user correlation across apps owned by different service providers. A user gets a different value in each app when using pairwise user identifiers. @@ -40,11 +40,11 @@ Within your application portfolio, the possibility to prevent cross-app user cor ### Keeping the Existing Logic and Extending -If your apps are not consistently storing the same identifier for a multi-app user in `system.user.name`, you can start using a new user attribute, new `UserCommons.namedUserIdentifier.value`.You can keep the existing application logic as it is, and in addition, store the selected user identifier value for a multi-app user in this new attribute. +If your apps are not consistently storing the same identifier for a multi-app user in `system.user.name`, you can start using a new user attribute, a new `UserCommons.namedUserIdentifier.value`.You can keep the existing application logic as it is, and in addition, store the selected user identifier value for a multi-app user in this new attribute. ### Paying Attention to Case Sensitivity -By design, the `system.user.name` is case sensitive and allows customers to store any user identifier without restrictions. If you choose to store an email address in these fields, or another identifier, that should be treated as case-insensitive. Mendix recommends downcasting such values to lowercase. The SAML, OIDC SSO, and SCIM modules already apply this for email claims/attributes received from your IdP. +By design, the `system.user.name` is case sensitive and allows customers to store any user identifier without restrictions. If you choose to store an email address in these fields, or another identifier, that should be treated as case-insensitive. Mendix recommends downcasting such values to lowercase. The SAML, OIDC SSO, and SCIM modules already apply this for email claims or attributes received from your IdP. For more information, refer to the [Versioning](/developerportal/deploy/implementing-user-metering/#versioning-information) section below. @@ -65,18 +65,18 @@ The user-role-based user classification module classifies users by using the rol ### Custom User Classification -This method can be implemented either by using the [User Classification](/appstore/modules/user-classification/) module or by creating fully custom microflows. The main advantage of this approach is the flexibility it provides- you can apply any classification logic you choose while still relying on the user classification module as the base. However, this method requires developing custom logic and involves upgrading your app to a new version of your app to include the [user classification](https://marketplace.mendix.com/link/component/245015) module. +This method can be implemented either by using the [User Classification](/appstore/modules/user-classification/) module or by creating fully custom microflows. The main advantage of this approach is the flexibility it provides. You can apply any classification logic you choose while still relying on the user classification module as the base. However, this method requires developing custom logic and involves upgrading your app to a new version of your app to include the [user classification](https://marketplace.mendix.com/link/component/245015) module. {{% alert color="info" %}} In situations where there is ambiguity about the user classification, Mendix considers users as internal users. Ambiguity may happen in the following situations: -* A multi-app user is marked as external in one app and internal in another app. -* When applying userrole-based classification, and a user has both an Internal and an External userrole. +* A multi-app user is marked as `External` in one app and `Internal` in another app. +* When applying userrole-based classification, and a user has both an `Internal` and an `External` userrole. {{% /alert %}} Classification by the platform is not supported by using your email domains, nor any other logic. Your app logic is responsible for classification. For more information, refer to [Custom Classification](/developerportal/deploy/populate-user-type/#custom-classification). -## (De)Activation of users +## (De)Activation of Users `system.user.active` attribute controls active or inactive users in your application. Users with an ‘active’ state can log in to your app and are counted for user metering purposes, while non-active users cannot login are not counted for user metering. @@ -86,14 +86,14 @@ You can provision the user records (for example, created, updated, or deleted) u * The SCIM module allows your app to be integrated with your IdP to create, update, or delete user records. Depending on the (configured) business logic in your IdP, users may be created, deactivated, or deleted * as a result of the Joiner/Mover/Leaver processes. - * as result of license optimization, users who haven’t logged in to a certain application for a certain period may be removed from the access group in the IdP, and therefore, the IdP may deactivate or remove users from your SCIM-enabled application. + * as a result of license optimization, users who have not logged in to a certain application for a certain period may be removed from the access group in the IdP, and therefore, the IdP may deactivate or remove users from your SCIM-enabled application. * The LDAP module allows you to synchronize users and their status (active=false/true) from your on-premises Active Directory to your application. This is a similar module to SCIM but using a different protocol. If you are considering deactivating or removing user records for optimization of user cost, you are advised to consider the following: * Users cannot log in when in the deactivated (active=false) state. The primary purpose of the active state is to control which users can log in. When SSO is used, the user may be successfully logged in at the IdP; however, the Mendix application fails to grant access if the active state is not updated. -* Actual logins, frequency of login, or system.user.lastlogin is also not relevant for metering. A user is counted as an active user if the state was active on any day of the calendar month. +* Actual logins, frequency of login, or `system.user.lastlogin` is also not relevant for metering. A user is counted as an active user if the state was active on any day of the calendar month. * If you choose to remove user records, associated data may be deleted depending on your domain model. * The SAML and OIDC SSO modules are capable of (re)creating any user that was deleted. This can be described as just-in-time user provisioning, also known as on-the-fly user onboarding or real-time user creation. @@ -118,7 +118,7 @@ The following are entities and their attributes: 1. `User`: Every Mendix app has a system module containing an entity `User`. - * `system.user.name`: This field is used to identify users, unless a UserCommons.namedUserIdentifier.value is available for the same user. + * `system.user.name`: This field is used to identify users, unless a `UserCommons.namedUserIdentifier.value` is available for the same user. * `system.User.Active`: A Boolean attribute, `Active`, is used to select the active user account for user metering. A user record that has `Active=true` during the metering period is counted as an active user during the billing period and reconciliated against one of the allocated user licenses. 2. `UserReportInfo`: The system module also features the `UserReportInfo`. @@ -127,7 +127,7 @@ The following are entities and their attributes: 3. `namedUserIdentifier`(optional): Recent versions of the [UserCommons](https://marketplace.mendix.com/link/component/223053) module include a `namedUserIdentifier` entity. - * `UserCommons.namedUserIdentifier.value`: User commons modules in your app model assign the values to the `namedUserIdentifier.value` attribute to identify a user instead of `system.user.name`.The `namedUserIdentifier` overrides `user.name`. + * `UserCommons.namedUserIdentifier.value`: User commons modules in your app model assign the values to the `namedUserIdentifier.value` attribute to identify a user instead of `system.user.name`. The `namedUserIdentifier` overrides `user.name`. Note that one application may use `system.user.name` and not `userCommons.namedUserIdentifier.value`, or may exclude the UserCommons module, while another application may use `userCommons.namedUserIdentifier.value` instead. If the values in these different fields are the same for a multi-app user, the Mendix user metering mechanism correctly identifies the user as a single multi-app user (deduplication).