Manage your clients

As a XLReporting partner, you can create and manage separate tenants for your clients.

Each client tenant is fully isolated (in terms of configuration, data, and users) from all other client tenants. Centrally, you can create new clients, view your existing clients, and manage (review, create and update) your defined objects, user roles, and users across all your client tenants.

Provided you have the relevant user permission, you can click on Actions - Manage clients in Manage Profile to open this window.

This window consists of 5 main options:

• Clients - an overview of your client tenants, the current usage, and the option to create a new client tenant.
• Objects - an overview of all defined objects (reports, models, imports, data sets) in your partner tenant, compared to the defined objects in each of your client tenants.
• Users - an overview of all users in your partner tenant, compared to the users in each of your client tenants.
• Roles - an overview of all user roles in your partner tenant, compared to the user roles in each of your client tenants.
• Groups - an overview of all menu groups in your partner tenant, compared to the menu groups in each of your client tenants.

Create client

In the clients overview, click on Create client to start creating a new client tenant. The client tenant will always be created with all active (non-locked) objects (reports, models, imports, data sets, user roles, and groups) in your partner tenant. Whether you also want to include the data and create the users is optional.

You will see a window with the following options:

• Client name - enter the client name.
• Copy current data - choose whether to copy the data in your partner tenant into the new client tenant.
• Copy current users - choose whether to add the users in your partner tenant into the new client tenant. Please note that the user who creates the client will always be added as user in the new client tenant, regardless of this option.

Update to clients

The other 4 options show a detailed comparison between your partner tenant (the "master version") and each of your client tenants (the "client version").

XLReporting enables you to customize objects (or create new objects, or delete objects) in client tenants, so that you can tailor the configuration to individual client needs. You have the option at any time to review any differences and sychronise the configuration of selected objects and/or clients again.

The last columns show an analysis of each object in each client tenant between your "master version" and the "client version". The Type of update column suggests the type of update that would be required to make the client object identical to the master version:

• Create in client - this object does not exist in the client, and it is safe to create it.
• Update in client - this object has a higher version number in the master compared to the client (so the master has a newer version), and no local version was marked so it is safe to be updated.
• Update+Rename in client - this object has a higher version number in the master compared to the client (so the master has a newer version), and its name has changed, but no local version was marked so it is safe to be updated.
• Delete in client - this object does not exist in the master (or no longer exists), and it is safe to be deleted.
• Client has its own object - this object has been created in the client, and it does not exist in the master. It will not be changed.
• Client has revised object - this object has a higher version number in the client compared to the master (so the client has a newer version, indicated by the minor version number). It can be updated, but any local changes made in the client will be overwritten.
• Different data set - the version number of this report, model, or import is identical in master compared to client, but it references a different data set in the client, compared to the master. It might have been changed without a marking a new version. You will need to decide if this is safe to be updated.
• Different fields - the version number of this data set is identical in master compared to client, but it has different fields in the client, compared to the master. It might have been changed without a marking a new version. You will need to decide if this is safe to be updated.
• Different queries - the version number of this model is identical in master compared to client, but it has different queries in the client, compared to the master. It might have been changed without a marking a new version. You will need to decide if this is safe to be updated.
• Ignore (locked in master) - this object is locked in the master, so it is ignored in the synchronization, regardless of whether the same object exists in the client.
• Ignore (same version) - the version number of this object is identical in master compared to client, and it will not be updated.

If you want to update changes after you have analysed the list, you need to select at least 1 type of update, select the objects and/or clients you want to update, and click the Update clients button. Please be very diligent when updating objects in clients, because this can not be undone.

The options Objects and Users show an extra option Update existing user roles: if you choose this option, the updated objects will be given the user roles as defined in the master tenant. Otherwise, the user roles will remain unchanged in the client tenant, even if the object itself will be updated.

Versions

When you define reports, models, imports, data sets, user roles, and menu groups, you can use Actions - Mark version to set a version number on the current definition of your object. XLReporting automatically numbers every next version, together with a description that you can enter. These version numbers are used to synchronize master versions to client versions.

Versions have a numeric xx.yy notation where "xx" is the major version number, and "yy" is the minor version number.

• When marking a next version in a standalone XLReporting tenant or partner tenant, only the major number will be incremented. So version "1.0" will increment to "2.0", then to "3.0" and so on.
• When marking a next version in a client tenant or sandbox tenant, only the minor number will be increased. So version "1.0" will increment to "1.1", then to "1.2" and so on. So for example, if a client tenant has an updated object with version "5.0" from its partner tenant, any local changes made in the client tenant will increment to "5.1", "5.2" and so on. Any subsequent changes made in the partner tenant will increment to "6.0", "7.0" and so on.

Logically, version numbers marked in partner tenants versus client or sandbox tenants can never intersect. This means you can always tell whether a version was marked in a client or sandbox tenant, or in a partner tenant. This versioning information is used when synchronizing objects.