Module 01: Tenant Overview

This module explains how your company is set up on OpenDataDSL: the tenant, its data environments, the people who use it, how their access is decided and what is kept separate from what. Most of it is reading, with a few short ODSL snippets you can run to look at your own tenant.

Learning Objectives​

By the end of this module you will be able to:

• Describe what a tenant is and view your tenant information
• Explain the difference between the production, preview and named data environments
• Describe how users sign in and how their access is decided
• Explain the difference between public and private data
• List which items are isolated in each environment

Step 1: The Tenant​

A tenant is your company's own space on the platform. It is created the first time someone from your company signs in to the Web Portal: they are asked for the company name and a few details, and from then on everyone who signs in with a work account from the same organisation joins the same tenant.

The tenant holds your company information and your tenancy configuration, such as service quotas, features and settings. You can view it with the tenant service:

//#region View your tenant
print ${tenant:""}
//#endregion

This prints, as JSON, your company information plus your service quotas and other configuration.

You can record your company details (name, address, email, phone, account contact) by saving an Object to the tenant service. See Tenant Service for the template.

Step 2: Data Environments​

A data environment is a physically independent space where your data, settings, workflows and scripts live. Each environment is a separate physical database in the same cluster.

The number of environments you can have is limited by your tenant's environment quota. By default this is 3, including production. You can request more from OpenDataDSL.

You will create and manage environments in Module 02.

Step 3: Users and Sign-In​

Users sign in with Azure Active Directory single sign-on, using their Microsoft work account. Personal email addresses cannot be used. OpenDataDSL never sees a user's password: authentication is handled by your own identity provider, so your IT team's rules (multi-factor authentication, conditional access and so on) apply.

There are three ways to connect:

To see who has connected from your company:

//#region List your colleagues
colleagues = find ${user}
print colleagues
//#endregion

Step 4: Roles and Policies​

Access is decided at two levels:

1. Application roles are Azure application roles, configured for your users by your own IT security team. Users with the admin role can always create, update and delete your company's policies.
2. Policies decide what each user can do with the data and what they see in the portal. They are records in the policy service.

When your company is onboarded, a default security policy called ManageAllPrivateData gives everyone (*) full access to all private data, and a feature policy called EnergyUserFeatures gives everyone the standard menu items. To restrict access you change, disable or replace these.

A few policies are built in and cannot be edited, such as ReadMyProfile-Built-In and ReadTenantUsers-Built-In.

You will work with policies in Module 04.

Step 5: Public and Private Data​

Every item belongs to a source:

Everyone in your company can read public data. Access to private data is what your security policies control.

Step 6: Resource Isolation​

The following are kept separately in each environment, so a change in test does not affect production:

• Actions, calendars, types and groups
• Objects (master data) and data
• Curve management information
• Extractors, transformers, scripts and workflows
• Processes and process execution records
• Report configurations and reports
• Security policies
• Audit records

Public items are shared by every environment, because they are not stored in your environments.

Exercise​

1. Run print ${tenant:""} and find your service quotas in the output.
2. Run find ${environment} and note which environments your tenant already has.
3. Run find ${user} and count how many colleagues have connected.
4. Run print ${user:"me"} to see your own user record.

Summary​