Multitenant Reports

In every Omniscope project users can create multiple reports, containing customised output, tailored for different audiences. In a scenario where the requirement is for a large number of recipients to access the same report which differs only in the data subset, there is a way to avoid duplication and large number of blue blocks sprinkled on the workspace.

Multitenant reporting is an Omniscope Evo feature that enables a tailored experience for different visitors, where the data subset powering the report is determined according to the user login details. In this setup only 1 report is serving multiple users or user groups e.g. marketing team will have a different login from the sales team, or from the management team. Once logged in, the marketing team will see only their performance data, while the management team will se all data on their dashboard.

Multitenant report facility is controlling what the recipient sees when they open the report link - it will not affect workflow-editing access.  You can learn more about how to share a report in this article.

Important - this feature is available only on the Evo Enterprise plan.

To setup Multitenant reports you will need to:

• Set up user authentication and report sharing  Multitenant reports will tailor the user experience based on the each user's credentials. Authentication can be set up through 
  • a) the report-defined usernames and passwords 
  • b) authentication through server folder permissions.  You can learn more on how to set up an authentication mechanism and set permissions in this article.    
    
    
• Configure Multi-tenant reports This configuration describes the variants of the report, and the conditions under which a variant should be displayed.  The configuration is read from a report input and it needs to have the correct structure. In this article we will show how to create some simple configurations. You can find the full reference in this article.

Note If a report visitor has edit permission on the report level, along with a multi-tenant report setup, then the edits permissions will be revoked for that specific report. 

If you do not need the security of multi-tenant reports, and simply want to create report URLs with custom initial filter configurations specified within the URLs, see URL parameters.

In the rest of this article we will describe how to set up a simple report access for multiple users. The report will show a different subset of records based on the user's credentials.

The Workflow

The workflow below shows a single data source connected a report block.

The report is also kept very simple:

Setting up user authentication and report sharing

Authentication through report defined usernames and passwords 

In the project file, open the sharing settings, then under Access level  select Authenticated through report defined usernames and passwords. 

Next add your user credentials as needed. In the example below, we added four users.

The report is now shared, and can be accessed via the external sharing URL.  The same report will be provided to every user however, as we haven't configured the multitenant reporting yet.

Authentication through server folder permissions 

In the Admin section of the App, click on "Branding Permissions & Parameters", then on "Edit Permissions". 

To implement user authentication, disable the anonymous user support by disabling everything in the Anonymous/Public user section.

Next, you should add groups as needed. In this example we will create three user groups: sales, marketing and admin. Each group will need to have project viewer permission (by default, this is inherited from the anonymous user), and a way to authenticate a user (For example List of users).

In the project file (the iox file with the workflow), open the target report and go to 

Report settings > sharing settings tab > Access level > Authenticated through Server folder permissions. 

This will enable the report to be served externally, but only to authenticated users (i.e. users of the groups we set up in the previous section), while all users will still view the same version of the report (we haven't configured the multitenant experience yet).  Proceed to the next section...

When using OpenId connect in server folder permission the user email will be used as username.
Configuring the multitenant report experience

Multitenant report setup uses a data-driven approach, where the configuration is read from a report input.

Each record taken from the multi tenant configuration input will be interpreted as a report variant / condition under which the variant should be applied. The intended effects of the report variant will only be applied if all the conditions for the particular record are satisfied.

The configuration settings could be delivered via any block, however this needs to have a prescribed structure: more specifically you might not have all the fields, or have some unexpected fields (i.e. a field which is not recognised as part of the configuration - not allowed!).
In this example we will use Text Input Block and manually set up the configuration.
We recommend to either use a Text Input block, a Storage block, or a Data Table block to configure and store the MTR configuration, as for those blocks Omniscope will always persist their data in full and never auto-cleaned them up.

Note If you wanted to use a Text Input block to define the configuration, a preset is already available in the block picker, called Multi-Tenant report configuration. This block will contain all the fields needed for the configuration, as well as some example rows.

• user : This field contains the user name of the report visitor. The condition is satisfied if the username matches the value in this cell. If left blank (or the field is not present), any user name will match: no user name will also match. 
• group : This field contains the name of the group the user is part of (if any). The condition is satisfied if the cell value matches the name of the group the user is a member of. If left blank (or the field is not present) any group (or no group at all will obtain access (i.e., when using  authentication through report defined usernames and passwords).
• filter : Variation of filtering values in a target field to be applied for different user groups. Filters can can be represented using a variety of formats. For this example we will use:
  <FieldName> = <value>. Where <FieldName>is the name of a field in the data set powering the report. In our example: we will use values such as (department = sales and department = marketing).
  You can find more information about filters formats in this article.
  Note Filters can only be applied to report data sources, and not the derived data sources.
• tabs: The names and order of the report tabs to include. Any tabs not in this list will be omitted. If left blank, all tabs will be included.
• branding: The branding file (.ILF) to apply. This can be be a relative or absolute path. If left blank, the default report branding will be used.
• notes : useful for storing notes about the variations and groups, no effect on the configuration

Some examples of configuration:

• Show only the records where department is equal to sales for the user sally, member of the sales group. Show only the 'Sales Dashboard' tab and apply some custom branding.
  
  
  This will not affect another possible user called 'sally' that is not a member of the 'sales' group, or another member of the sales group whose username is not 'sally'. Even if the user name sally appears in the report username and passwords list, it will not match, as the user is not a member of the sales group.
  
  
• Show only the records where department is 'marketing' to every user member of the 'marketing and R&D' group. Show only the 'Marketing Dashboard' tab. Use the default branding.
  
  
  
• Allow the admin user to view all data. Show all tabs and use the default branding.
  
  
  This will match any user called 'admin' regardless of the group they are part of. Also note that we are not filtering any records here, as the filter cell was left blank

Note It is possible for some user credentials to match more than one of the configuration records. In this case the first record satisfying all conditions will be used to customise the report experience.

In our example we will be using authentication through report defined usernames and passwords:

• The user named sally to have access only to the records where the field department is equal to sales
• The user named mark to have access only to the records where the field department is equal to marketing 
• The user named adele to have access to all the records
• The user named mary (also any other users not configured above) to have access only to the records where the field Job title is equal to CEO

Our configuration will like

The final step is to set this input as as a multitenant report configuration input, so that Omniscope is aware that this data should be interpreted as configuration data.

Open the report sharing options in the report block, and set the "Configuration Input" under the "Multi-tenant report configuration" to be the text input block we just created.

This report input cannot be used to power the report, or to create derived sources.

To test everything is working we just need to click on one of the URLs to share the report, and access the output with different users.

One final remark is that configuration and multi tenant report setup will only take effect on the shared report (link found under the sharing settings in the report).

You can find the .ioz file used in this tutorial attached to this article, password for every user is password