Linked Data Connections - BETA

It is possible to link data connections together. This can have the following benefits.

  • If common structure is repeated - it means it is created and maintained in one place.

  • Content can be visible but locked away from users, who can otherwise edit a data connection.

Specifically in Multi-Organisational environments

  • You can allow tenants to build their own content on top of the standard shipped data connection.

  • Tenants can create content against a database - without being given or even able to view any Database connection details.

  • Tenants can have user restrictions applied to their own data connections - that they are not able to remove or alter.

There are use cases for linked data connections to be used within a single Organisation, however it is often used in conjunction with Organisations to provide additional security.

How to tell if my data connection is linked?

When you open a linked data connection, if you notice that a table has a hashed line around it then this table is from the linked data connection.

image-20240827-100743.png

Also notice that some of the objects in this table a greyed out.

These objects also come from the ‘parent’ data connection so cannot be edited or deleted here.

image-20240827-101024.png

They are read only.

If you see such a structure this is the first indication that you are working on a linked data connection or a ‘child’ connection.

If you now look at the connection tab,

image-20240827-101149.png

We can’t see any of connection details. If we want to change any of the specifics about the connection to the database then we would have to edit the parent data connection. In this example that is a connection called Ad Spend. You may not be allowed to edit the parent, and the parent may even be in another organisation.

Creating a Linked Data Connection

The parent data connection is created and maintained as any other data connection. When you decide that you want this data connection to become a parent data connection, you tick the ‘Can Have Child Connections’ box on the Connection screen.

image-20240827-101913.png

Now we can create a child from the parent. To do this create a connection as normal, but instead of setting the database credentials, we use the ‘Parent Connections’ droplist to select the parent to inherit from.

image-20240827-102136.png

This list contains all the data connections you have access to, to appear in this list the following criteria must be met.

  1. The data connection must be marked to allow child data connections.

  2. You must have access to the category that the data connection belongs to.

  3. If the data connection belongs to a different organisation, then you must have a subscription to that organisation, with access to the category that the data connection belongs to.

Once you have selected the parent data connection and saved.

image-20240827-102545.png

The connection panel changes, At this moment the child data connection is attached to the parent. You are not allowed to remove the parent from this data connection. (A life long bond has been established). You cannot set a child to allow other data connections to be children of it. We allow only 1 level of inheritance.

You have the ability to transform an existing data connection into a child at any point, but it's important to approach this process with caution!

Now that our data connection is linked , i.e. it is a child, we can add local content to it.

You add tables / objects and joins as you would with any other data connection. The only difference is that you can’t edit any of the content that comes from the parent.

You can add objects to tables that come from the parent though.

image-20240827-114550.png

If anyone creates new content in the parent data connection it will automatically appear in your child data connection.

You can only edit content in the child when you are in the child.

Always make sure you do join your tables back to the content of the main data connection. If the admin in the parent connection creates a user restriction for you, all your queries will fail with a SQL error (this is intended) until you link back to the main structure.

Exporting / Import A Child Connection

You cannot currently export / import child connections.

Using a Child Data Connection

It makes no difference to the user in the Edit Chart screen, the child data connection is presented to the user, without making them aware of which objects come from the parent and which from the child.

 

image-20240827-115243.png

Linked Data Connections + Organisations

If we are giving one of our tenants the ability to create data connections then we probably do not want to.

  1. Share the database connection details with them.

  2. Not allow them to create a child from any of our data connections. We want them only to be able to use specific seed data connections.

  3. Do want to enforce any [[VARIABLE]] replacement in the data connection details.

  4. Enforce database tenancy using user restrictions (or Variables).

  5. Share a set of default content that can be used as a starting position.

The configuration will look a little like this;

image-20240827-121436.png

It is very important that all of the security related details are configured in the top level organisation.

Worked Example

I have my 2 organisations - Organisation 1 is the Owning Organisation.

image-20240827-153749.png

Now I switch over to the Tenant Organisation (B)

I now create a user in Organisation B - the tenant organisation.

image-20240827-154017.png

Now I switch over to the Owning Organisation (A)

Then I’ll create the parent data connection in Organisation A. I am going to use [[VARIABLES]] on the role so that different tenants could get redirected to different DB’s / Accounts. I will also check the Can Have Child Connections option.

image-20240827-154648.png

I’ll add some quick content to the data connection.

image-20240827-155135.png

Now I make sure that the data connection Belongs to a specific category (I could leave it at Home - but this is better).

image-20240827-155345.png

Now I create a role - that can control access.

image-20240827-155433.png

I could control the variables on the user subscription, but in this example I am going to use the role. I mark the variables as secure. I don’t want any users to find these values.

image-20240827-155540.png

Next we’ll add a user restriction on the tenant organisation (B) user (B)'s subscription in the owning organisation (A). I’ll put a restriction on so that the user can only view data for the store in Leeds.

image-20240827-160815.png

 

Now I create a subscription at viewer level for the user in the tenant organisation (B) in this owning organisation (A).

image-20240827-155844.png

I can check this is users / subscriptions

image-20240827-155922.png

Now we grant access to the role in the owning organisation (A) to the subscription of our User (B) from the tenant Organisation (B).

image-20240827-160320.png

Now we will log into the dashboard as the user (B) from the tenant Organisation (B).

We go to the admin panel and the data connection screen.

Now we can create a data connection. Using Data Connection A from the owning organisation (A) as the parent. When I save the connection - it’s connection details go green (actually it passes me straight the data tab because it validates). I am connected to the database but cannot see or control any of the connection details.

image-20240827-160541.png

I will see all of the inherited content.

It’s content is read only for the objects.

image-20240827-161150.png

I can now add to the connection, all whilst having my user restriction enforced and data connection defined by variables. Most importantly all of these details are locked away in my subscription in the owning organisation (A).