Data Groups

Introduction

All instances of the Entities are now stored in the Groups.

Data Sources, Lookups, Custom Actions, Roles + Themes.

Groups can be created to correspond to a project environment, e.g. Test Group and Prod Group, where Test Group stores test entities and is applied to a Test Project, and Prod Group stores production entities and is applied to a Prod Project.

There can also be a shared group, that can store entities relevant to both Test and Prod projects.

Groups can be created on the Groups page.

Duplicated entities

Duplicated entities are those instances that are created (duplicated) for each group separately.

The following entities are duplicated:

• Portals (depends, the explanation is ahead)

• Services

• Tables

• Maps

Portals

• If test and prod data are stored on different portals then two portals should be created and applied to the corresponding groups

Services, Tables, and Maps

Services are separate instances and must be applied to one specific group, as well as the tables and maps.

In the case of duplicated entities deleting an entity from one group won’t delete it from another one.

Non-duplicated entities

Non-duplicated entities are those instances that are created once and are assigned to several groups.

The following entities are non-duplicated:

• Portals (depends, the explanation is ahead)

• Lookups

• Custom Actions

• Roles

• Themes

Portals

• If test and prod data are stored on the same portal only one portal should be created and applied to both test and prod groups

In the case of non-duplicated entities, it is important to know that deleting such an entity in one group will delete it from both groups.

So in case when entity should be removed from a group it is better to unlink the group, not delete the entity.

Groups cloning

The purpose of cloning groups is to create an additional new group with all existing instances of the source group

When a group is cloned >>

• all duplicated entities from a source group will be cloned (created again) and applied to a cloned group

• all non-duplicated entities from a source group will not be cloned (created again)

• the existing ones will be applied to an additional (cloned) group

Groups merging

The purpose of group merge is to deliver all new instances from the source group to the recipient group.

During the merge, the instances that exist in the source group will be duplicated or assigned to a recipient group (depends whether the instance is duplicated to non-duplicated).

An example of a non-duplicated data merge:

A new lookup (non-duplicated instance) is created in the scope of the Test group

Then the Test group is merged into a Prod one

A Prod group which is a recipient is now applied to a lookup

An example of a duplicated data merge:

A new service is created in the scope of the Test group

Then the Test group is merged into a Prod one

The service is created as a new instance in the prod group

This logic is based on the key field.

During the merge, the instances of the source group and the instances of the recipient group are checked on the key field:

• If the instance with the same key from the source exists in the recipient group, new data is not created

• If the instance with the same key from the source does not exist in the recipient group, new data is created

The key field exists in any instance of the group >> lookups, data sources, custom actions, etc.

Groups and projects relations

Technically one or more groups can be assigned to a project.

In the case of the UVM project, one group is applied to each project:

• Test group is applied to a Test project

• Prod group is applied to a Prod project

Projects cloning

When a project is cloned the user can select a group that will be applied to a new cloned project.

Depending on the selected group its instances and its data will be applied to the new project.

Projects merging

When a new configuration is done for a project using new instances of a group, before merging projects, it is necessary to merge groups.

Otherwise, new instances will not be included in the recipient project, only the new configuration will be delivered.

So the best practice is to always merge group into group before merging projects