You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/control-center/entitlements/cloud-tokens.md
+5-1Lines changed: 5 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -90,7 +90,10 @@ These tables show how many Mendix Cloud Tokens each CRP requires:
90
90
| 3XL | 640 |
91
91
92
92
{{% alert color="info" %}}
93
-
You can no longer purchase Legacy CRPs. You can now only purchase and provision Standard, Premium, and Premium Plus CRPs. Any legacy CRPs that you have already purchased will be converted into Mendix Cloud Tokens if they are deprovisioned. This will use the rate specified in the previous tables, and the Mendix Cloud Tokens will be added to your Token pool.
93
+
94
+
* You can no longer purchase legacy CRPs. You can now only purchase and provision Standard, Premium, and Premium Plus CRPs. Any legacy CRPs that you have already purchased will be converted into Mendix Cloud Tokens if they are deprovisioned. This will use the rate specified in the previous tables, and the Mendix Cloud Tokens will be added to your Token pool.
95
+
* Self-service cloud consumption capabilities are exclusively available for Standard, Premium, and Premium Plus CRPs. If you are using a legacy CRP, you may experience consumption inaccuracies in the self-service tool. For access to the latest capabilities, Mendix recommends contacting your customer success manager to transition to a Standard, Premium, or Premium Plus CRP.
96
+
94
97
{{% /alert %}}
95
98
96
99
## Key Takeaways
@@ -100,3 +103,4 @@ You can no longer purchase Legacy CRPs. You can now only purchase and provision
100
103
* You buy Tokens in advance, and can use them to obtain CRPs.
101
104
* If you no longer need those resources, you can reuse the Token to obtain other CRPs, or keep it to be used later.
102
105
* Mendix Cloud Tokens expire on the end date of their associated contract. To ensure continued access, please renew your contract before it expires.
106
+
* Mendix Cloud Token balances might be incorrect if you still use a legacy CRP.
Copy file name to clipboardExpand all lines: content/en/docs/deployment/general/populate-user-type.md
+78-15Lines changed: 78 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,9 @@ aliases:
8
8
9
9
## Introduction
10
10
11
-
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.
11
+
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.
12
+
13
+
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.
12
14
13
15
{{% alert color="info" %}}
14
16
**Definitions**
@@ -22,58 +24,119 @@ In your Mendix Pricing Plan there is a distinction between Internal and External
22
24
23
25
## Background
24
26
25
-
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.
27
+
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.
26
28
27
-
The *Mendix Metering* module relies on this attribute to ascertain the end-user type and report it back to us.
29
+
The metering relies on this attribute to ascertain the end-user type and report it back to us.
## Assigning UserType for Existing Users of IAM Modules
33
+
## Classification Options
34
+
35
+
There are several approaches to classify users as `Internal` or `External`, ranging from configuration-only to custom development. These options are listed below:
36
+
37
+
### IdP-Based User Classification
32
38
33
-
The simplest method to set the user type is by using the Identity and Access Management (IAM) modules, which require only configuration without the need to develop a microflow. Mendix offers you the following IAM modules:
39
+
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](#using-microflow) section below.
40
46
41
-
When connecting your app with an IdP, set up the user type through the capabilities of the OIDC SSO, SCIM, or SAML module. The user type 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 **User Provisioning** tab of your app. Based on this configuration, users are updated each time they log in. These modules allow you to set the user type per IdP as the source of your end-users, assuming that separate IdPs are used for `internal` and `external` users.
47
+
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.
42
48
43
49
For more information, refer to the User Provisioning section of the following modules:
#### Prerequisites for IdP-Based User Classification
56
+
57
+
1. Mendix and module versions:
58
+
* Mx9
59
+
* OIDC SSO: v3.0.0 or above
60
+
* SCIM: v1.0.0 or above
61
+
* Mx10
62
+
* OIDC SSO: v4.0.0 or above
63
+
* SAML: v4.0.0 or above
64
+
* SCIM: v2.0.0 or above
65
+
* Mx11
66
+
* OIDC SSO: v4.0.0 or above
67
+
* SAML: v4.0.0 or above
68
+
* SCIM: v2.0.0 or above
69
+
70
+
2. IdP Setup: Use separate IdPs for `Internal` and `External` users.
71
+
72
+
{{% alert color="info" %}}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 different `UserType` values per IdP connection. Configurations in your IdP have to ensure that each client only addresses internal or external users.
73
+
{{% /alert %}}
74
+
75
+
3. 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.
76
+
77
+
### User Role-Based User Classification
78
+
79
+
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](https://marketplace.mendix.com/link/component/245015) module, which aims to streamline the implementation of user role-based classification, thereby minimizing the development effort required within the application.
80
+
81
+
Instead of writing microflows, you can classify users as `Internal` or `External` using roles in the User Classification module. To do this:
82
+
83
+
1. Define roles like `ExternalRole` or other custom roles.
84
+
2. Use the [User Classification](/appstore/modules/user-classification/) module to map these roles to the `UserType` field in the `UserReportInfo`.
85
+
3. When a role is assigned to a user in your Mendix app, the User Classification module automatically updates the `UserType` field in the `UserReportInfo` entity for that user.
86
+
87
+
This approach is simpler, more consistent, and easier to maintain than attribute-based logic.
88
+
89
+
For more information, see the [Role-based Classification](/appstore/modules/user-classification/#role-based-classification) section of *User Classification*.
90
+
91
+
#### Prerequisites for Role-Based Classification
92
+
93
+
1. Your app model uses distinct user roles for external and internal users.
94
+
2. Include the User Classification module in your app model. To use it, your app must be running on one of the following Mendix versions:
95
+
96
+
* Mx9 LTS
97
+
* Mx10 LTS
98
+
* Mx11 and above
99
+
100
+
### Custom Classification
101
+
102
+
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.
103
+
104
+
#### Custom Classification Using the User Classification Module
105
+
106
+
This option lets you build custom logic while still using the framework from the [User Classification](/appstore/modules/user-classification/) module. It reduces development effort by giving you a structured way to add custom classification rules.
107
+
108
+
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](/appstore/modules/user-classification/#custom-classification) section of *User Classification*.
109
+
110
+
#### Custom Classification Using Your Own Microflow
111
+
112
+
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.
50
113
51
114
{{% alert color="info" %}}
52
-
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.
115
+
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.
53
116
{{% /alert %}}
54
117
55
-
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.
118
+
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.
56
119
57
-
### Domain model
120
+
#####Domain Model
58
121
59
-
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.
122
+
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.
60
123
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.
2. Create a microflow `User_EvaluateAndSetUserType` which will populate the `UserType` attribute on the `UserReportInfo` entity for a given `User`.
73
136
74
-
In this example, we decide whether a user is `Internal` or `External` 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 the `System.User` entity itself does not have the email address. The email address is stored in specializations of `System.User`.
137
+
In this example, we decide whether a user is `Internal` or `External` 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 the `System.User` entity itself does not have the email address. The email address is stored in the specializations of `System.User`.
75
138
76
-
Here, we show how to do it for two specializations of the `System.User` entity, namely `Administration.Account` and `MendixSSO.MendixSSOUser`. In the `Administration.Account` entity, the email is in attribute named `Email`. And in the `MendixSSO.MendixSSOUser` entity, it’s in an attribute named `EmailAddress`. Hence we need to use an [Object Type Decision](/refguide/object-type-decision/) activity to split the `System.User` into `Administration.Account` and `MendixSSO.MendixSSOUser` and then fetch the email address according to the name of the attribute.
139
+
Here, we show how to do it for two specializations of the `System.User` entity, namely `Administration.Account` and `MendixSSO.MendixSSOUser`. In the `Administration.Account` entity, the email is in an attribute named `Email`. And in the `MendixSSO.MendixSSOUser` entity, it’s in an attribute named `EmailAddress`. Hence, we need to use an [Object Type Decision](/refguide/object-type-decision/) activity to split the `System.User` into `Administration.Account` and `MendixSSO.MendixSSOUser` and then fetch the email address according to the name of the attribute.
If you want to deploy your app to Amazon EKS, consider using the Mendix for Amazon EKS Reference Deployment. For more information, see [Mendix for Amazon EKS—Terraform module](https://aws.amazon.com/solutions/partners/terraform-modules/mendix-eks/).
21
+
If you want to deploy your app to Amazon EKS, consider using the Mendix for Amazon EKS Reference Deployment. For more information, see [Mendix for Amazon EKS—Terraform module](https://registry.terraform.io/modules/aws-ia/mendix-private-cloud/aws/latest).
0 commit comments