Tenants and subtenants

A tenant is the place where all your flows, values, service integrations and content are stored, and accessed from using the Boomi Flow drawing tool.

A subtenant is a new tenant under the same tenant account. Subtenants do not have visibility into the content, flows, values, or service integrations of the tenant (and vice versa).

You can use different subtenants for different divisions of your company. For example, separate subtenants for HR and Accounting. Subtenants can also help to organize your project, for example, you can logically separate out deployment environments into Development, Staging, and Production.

If the logic gets too varied, it may be more appropriate to package and deploy the flow into another tenant/subtenant – effectively cloning it so the flows don’t get unmanageable. It’s important to note that when you package and deploy a flow into another tenant, all of the unique identifiers of all of the elements in the flow remain the same. So if you make a change in one flow, you can replicate that change in other tenants simply by copying and pasting the changed Element JSON.

When organizing your project, it can be useful to have tenants and subtenants to separate out changes. A few reasons you might do this:

You have a set of template flows that you want to keep as the “master” version. You then deploy these template flows into another tenant if it’s not adequate for a particular use-case. You can easily package and deploy the template flows into as many other tenants as you like. This can also be helpful if you want to “clone” the flow for any reason.

You want to logically separate out deployment environments into: Development, Staging, Production, etc. If this is the case, you should always make changes in the Development tenant as moving packaged flows “up the stack” will overwrite changes. If you have to make a change in Production/Staging, you’ll need to rigorously ensure you make that same change in Development or the next time you package and deploy, it will be lost (or more accurately, it will be in a historic snapshot, but it will take a lot more effort to find it and merge it back).

You want to restrict access to certain flows to particular team members, groups or customers so changes are not made inadvertently by another user. A tenant and its subtenants currently share the same identity access rights. So authoring users in the main tenant can provision themselves into a subtenant without requesting access (currently). Separate tenants have separate permissions.

Tenants can all talk to the same database (through services). So you can have many different tenants acting on a central data repository.

Tenants and subtenants are basically the same – however – you can login to a tenant and its subtenants using the same password (with a slightly changed username: [email protected]{sub-tenant name}+{tenant name}.manywho.com.

Tenants all have different usernames/passwords so you need to manage multiple credentials.

Recommendations:

Have a tenant for the generic flows and each industry. So a tenant for each industry that holds the generic flows that should be used by all “standard” customers. Under each tenant, there should be a subtenant for Development, Staging, and Production.

Have a tenant for each customer that various from the standard template.

If you are packaging a flow and deploying into another tenant, treat this as a one-time operation if you are planning to edit the flow in the target tenant. When a package is deployed, it overwrites all changes in the target tenant. As a result, any changes made by flow builders will be lost (though can be found through querying the SnapShot API).