This page describes how users are managed in Orbit One, and specifically:

• How users' roles define their capabilities on the platform.

• How users can be sourced from analytics platforms linked to Orbit One.

Roles

Users with access to Orbit One and the platform’s other modules, can have one of the following four roles.

Orbit One Administrator

• Has the ability to manage all Environments in an Organization. In other words, they’d be responsible for connecting an Environment by adding the necessary credentials (REST API PAT token, interactive Vizportal sign-in, …).

• Has the ability to manage other aspects of an Organization, e.g.

  • “Allowed email domains” that control which email address domains can register for Orbit One.

  • Set up integrations like Cloud Storage, Slack, Teams, OpenAI, etc.

• Has the ability to manage users who have access to the Environments in the Organization.

• Automatically circumvents all source environments' permissions as Orbit One grants them access to all content in their Organization.

• Perform Administrative tasks specific to their Organization and its Environments.

• Typically use all modules including Connect, Admin Superpowers, and Health and Monitoring.

Environment Administrator

• Has access to some of the resources in an Organization, and full access to one or more of its Environments. An Environment Administrator in Orbit One, is typically still a Tableau Site/platform Administrator and Tableau specialist in their own company, if they have access to this tool.

• Automatically circumvents the permissions of the source environments they have access to, within their Organization.

• Perform Administrative tasks specific to their Environment.

• Typically use all modules including Connect, Admin Superpowers, Insight Messaging, and Health and Monitoring.

Analyst

• Has access to resources in one of more Environments connected to Orbit One.

• Represents a typical specialist/analyst in a company, such as Tableau Creators and Power BI Members.

• Permissions that apply for a user within an Environment, are applied by Orbit One.

• Typically use analyst modules like Insight Messaging, and Broadcast, to elevate, enrich, and propagate their analytics products.

Viewer

• Represents the wider audience of analytics consumers in an Organization.

• May have access to a single Environment, or several Environments in an Organization.

• Permissions that apply for a user within an Environment, are applied by Orbit One.

• Typically use consumer modules such as the Orbit One Portal.

User Sync & Mapping

The concept of “User Sync & Mapping” describes Orbit One’s ability to:

• Sync/ingest users from the environments (platforms) it is connected to.

• Use certain logic to determine which platform user corresponds to which Orbit One user, which is maintained as a user mapping.

User Sync

The User Sync is one of the Connect module’s capabilities that can be scheduled. Each time that sync is run, the users will be read from Orbit One’s database (i.e. User entities for that environment), and compared against existing Orbit One users.

If desired, non-existent users can be created (from source ➡️ to Orbit One), but existing users will not be modified or deleted (because it is not possible to do so based on a single environment’s user list). Any user that is created automatically on Orbit One, will have a Orbit One role of Viewer. Whether users are actively created on Orbit One or not is driven by a setting on the Users admin page, under User Sync & Mapping. That is also where User Mappings (described below) are configured.

User Mapping

Theory

For a user to be created or matched on Orbit One, it must be mappable to an email address. There is a fixed logic used to determine how the mapping of a user to an email address will take place.

1. Specific mapping
   Orbit One can prioritise explicitly defined user mappings over any other rule. fall back to a specific mapping of usernames to email addresses. This mapping can be provided per environment and consists simply of a dictionary with key and value: username and email.

2. Platform username
   If the username of the user on the platform (Tableau, Power BI), … is a valid email address, this is the primary choice.

3. Platform email attribute
   If the username is not an email address, but an email address is associated with the user account (e.g. sourced from Active Directory in Tableau), then that is the next choice.

4. Extensive mapping
   If no specific mapping exists, Orbit One can ultimately use regular expressions as part of “extensive mapping”, to transform a username into an email address. It should be possible to always land a match with this last-resort technique. This extensive mapping can be provided per environment and consists of a set of regex patterns, and replacements to go with them. Like specific mappings, this is a dictionary with key and value representing regex_pattern and regex_replacement respectively.

Examples

To better understand how Orbit One User Mapping works, here is a scenario against which we can apply our user mapping rules as part of a User Sync task. Imagine we are starting with the following users in Orbit One, and in a Tableau environment (usernames listed in no particular order on either side):

On top of that, we have our “specific mapping” rules, and “extensive mapping” rules:

• Specific mapping with two entries
  vermet2 timothy.vermeiren@biztory.be
kerine.taylor@biztory.co.uk kerine.taylor@biztory.com

• Extensive mapping with one regex rule
  (.*) $1@biztory.com
  That’s a regular expression saying: append @biztory.com behind any user you find.

Let’s go through the Tableau usernames one by one to understand both the mapping logic and the action to be taken:

• timothy.vermeiren@biztory.com

  1. Does not have a matching entry in the specific mapping table. Next mapping rule.

  2. Has a direct match with its platform username on Orbit One.
     Action: user exists, so they’re not created. We do register the mapping between the Tableau and Orbit One users.
     
     

• lex.pierik@biztory.nl

  1. Does not have a matching entry in the specific mapping table. Next mapping rule.

  2. Does not have direct match with its platform username on Orbit One. Next mapping rule.

  3. Imagine this Tableau user has its email attribute set to lex.pierik@biztory.com: this is a match with their user on Orbit One!
     Action: user exists, so they’re not created. We do register the mapping between the Tableau and Orbit One users.
     
     

• vermet2

  1. Has a matching entry in the specific mappings table (timothy.vermeiren@biztory.be)!
     Action: user does not exists, so they’re created. We register the mapping between the Tableau and Orbit One users.
     
     

• kerine.taylor@biztory.co.uk

  1. Has a matching entry in the specific mappings table (kerine.taylor@biztory.com)!
     Action: user does not exist, so they are created. We also register the mapping between the Tableau and Orbit One users.
     
     

• fabian.zimmer

  1. Does not have a matching entry in the specific mapping table. Next mapping rule.

  2. Does not have direct match with its platform username on Orbit One. Next mapping rule.

  3. Does not have match with its platform email address on Orbit One. Next mapping rule.

  4. Applying the extensive mapping rule that remains, fabian.zimmer becomes fabian.zimmer@biztory.com. This is a valid email address.
     Action: user does not exist, so they are created. We also register the mapping between the Tableau and Orbit One users.
     
     

• anna.bossmann@biztory.de

  1. Does not have a matching entry in the specific mapping table. Next mapping rule.

  2. The platform username is a valid email address.
     Action: user does not exist, so they are created. We also register the mapping between the Tableau and Orbit One users.

As a result, we have the following environments “in sync” and mapped:

Example Specific Mappings

From the example above:

Example Extensive Mappings

From the example above: