Best practice for a standard product

We are developing a standard product. For very large customers or white label business partners we would like the option to deploy the product in either a seperate (private) cloud node or to deploy it on premise. To manage the different versions we would like to define a single Mendix project and create a branch for each version released. For this matter we would like give the cloud nodes the names like "standard", "label A", "customer B". For example this might lead to the following nodes and versions of the product: Node "standard" contains version 2.3.1 Node "label A" contains version 2.2.0 Node "customer B" also contains version 2.2.0 We don't get this to work because Mendix does not allow us to select the same project for different nodes. What is the best practice to handle our situation?
4 answers

At Daywize we have the same problem. We do create seperate branches for each customer. And it is no problem that these branches are not connected to a cloud slot. You just have to create mda that you upload yourself.

There are still some problems we hope Mendix will solve. For instance, you can change the feedback widget project ID for each branch, but it would be nice if I also could point the modeller to right project ID. Because now it will show me the feedback of the main branch instead of the client branch. We put a feature request for that. And yes, it would be real nice if we could manually set the node. Then even the Deploy to cloud button would work. I suggest filling feature requests. If more partners want these kind of features they may consider implementing them.




You can create SAAS solution for this. That means that every user is linked to a client and sees only his client' data. This is also known as multi-tenant. It would need a full blog to describe, but in short:

  1. Accounts are associated to a client (tenant)
  2. Create a role 'ClientApplicationManager' and a user per Client with that role to create users within clients.
  3. Associate ALL data in your model to the Client entity.
  4. Set accces rules to all entities and click 'Path to user' (Orders/Orders _ Client/Client/Client _ Account = '[%currentuser%]'). Path to user is a help, you can do it by hand.
  5. Make an 'After create' event for all data in your model that associates to Client, retrieve Current client, Change Order, Orders _ Client = $CurrentClient.
  6. Set 'Apply entity access' True on all microflow, except system background and Admin stuff. This is essential. If you retrieve the first client with entity access it will retrieve only the client you belong to, without entity access it will retrieve all. That is deadly in a SAAS environment.
  7. Don't use FileDocument directly, always inherit.

This is the bare mininum. Don't skip one step. Don't skip testing phase.


To add on to Chris's idea - I have created a similar structure. I also needed to offer different features/capabilities to different clients, based on their subscription level. To accomplish this, I added boolean attributes to the Client entity for each feature I wanted to be able to turn on and off. Then within the application, tabs, buttons, etc. that provide access to the premium features can be turned on and off in a Client configuration page accessible to a 'Super Administrator' role, i.e. not a Client user but an administrator of the overall system. In this way, once a client orders a new feature, turn the switch on and it is available for him.


Mendix can't provide the option to have multiple acceptance and production environments with 1 teamserver project. It is 1 project with 1 acceptance and production environment.

It is possible to build 1 solution for multiple customers, but it has his challenges. The biggest one is the performance and security in the model. The data must be separated with the entity access by adding Xpath constraints, just as Chris de Gelder describes. Those queries will slow down the performance. Another disadvantage is your styling. You can't add custom CSS styling per customer. Of course you can add styling options in your model, but that will also slow down the performance of the screen. The application has to calculate and render more before showing the complete form.

There is a workaround for this problem. It is possible to upload an MDA to a public cloud node. You can start per customer a Mendix project and do nothing with the teamserver, but use the cloud nodes that are attached. Upload a MDA to the project and place them in the cloud node.