These design principles worked for us.
Each Tenant is developed separately in it’s own project and then all the modules are exported and imported into the hosting project.
The modules/tenants use their own page layouts and most importantly their “menu document” so that they are independent of the project navigation. Having it’s own navigation free’s each app to build it’s own navigation structure. You can build admin pages etc. also by duplicating those pages with tenant specific layouts.
Finally use the deeplink module to give a separate URL for each tenant.
As user navigates to each of these link his navigation is boxed/restricted to the layout/menu combination of each tenant.
This way a user can have access both the tenant apps if needed but will get completely different experience because of the layout/menu he is tied to.
Finally some naming convention to tenant specific User Roles definitely helps.
If you use SAML module – you can use custom user provisioning to assign tenant specific roles based on SAML response attributes if you need some automation to role assignment.
Deployment is the same because it will be one app with one database. There is a demo module in the appstore: https://appstore.home.mendix.com/link/app/80498/Mendix/Multi-tenant-administration
Create a tenant object that you associate to the user entity, so that a user belongs to a tenant.
For other entities make sure there is a path to the tenant and therefore the user, then using the xpath in the access rules of the entity make sure to set a path to the user via the tenant and compare this with tthe currentuser. Now the records in the entity will only be shown if the record is associated to the same tenant as the user is.
As for routing or mapping data from integrations. Find a unique identifier from an integraton and store that within the organizaton or a table that is only linked to that organization. This way, you can identify the correct organization.
We use a seperate API user with limited rights, if you are also going to do this remember that you cannot base the organizaton on the current user because the API user is not connected to it.