If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

Configuring Workflows and Permissions

Workflows in MDM Web App are a means to move changes made to records between logical states to ensure the four-eye principle or other approval mechanisms.

Changes to records are stored inside drafts. A draft can contain changes to multiple records, which can then be published all at once.

There are two strategies you can employ when working with workflows in MDM Web App:

Use the default built-in workflow and permission scheme.
Configure one or several custom workflows and a custom permission scheme.

Custom permission schemes must be configured with custom workflows. It is not possible to use a custom permission scheme with the default built-in workflow.

Default master data workflow and permissions

The following diagram represents the default workflow (consolidation workflow) for editing data in the Consolidation hub. The circles represent statuses between which users move drafts in MDM Web App while the arrows represent transitions (the ability to move drafts between specific statuses).

Default master data roles and permissions

The following table summarizes the default permission scheme.

To change the default role-to-permission assignments, see Assigning roles to default permission types.

Permission type Consolidation permissions Role assigned by default

Permission type	Consolidation permissions	Role assigned by default
Viewer	Can browse all entities but cannot perform any actions.	`MDM_viewer`
User	Can perform all actions on records and workflow transitions from the Published and In Progress state. Cannot perform the Publish transition from the In Progress state.	`MDM_user`
Admin	Can perform all actions on records and workflow transitions from all states.	`MDM_admin`

Viewer

Can browse all entities but cannot perform any actions.

MDM_viewer

User

Can perform all actions on records and workflow transitions from the Published and In Progress state. Cannot perform the Publish transition from the In Progress state.

MDM_user

Admin

Can perform all actions on records and workflow transitions from all states.

MDM_admin

Enabling the default workflow

To enable the default workflow and, if necessary, customize the labels of statuses and transitions:

Open the MDM Engine project in ONE Desktop.
Double-click the GUI Configuration project node. Select Workflow Configuration tab.

All the settings pertaining to the default workflow are under Default Workflow Settings.
Check Enable Default Consolidation WF.
Customize the labels for the steps and transitions as needed.
Right-click GUI Configuration and select Generate. Now the mda-workflow.gen.xml file has been updated with the new configuration, and you can deploy it to the application server running the MDM Engine.

Assigning roles to default permission types

Open the MDM Engine project in ONE Desktop.
Open Files > etc > mda-permissions.xml.
Make sure that only the MdaDefaultPermissionsProvider security provider is enabled and all others are commented out.

Under each permission type, list the roles that should have these permissions.

In the following configuration, users with role MDM_viewer have Viewer permissions, those with role MDM_user have User permissions, and those with role MDM_admin have Admin permissions.

mda-permissons.xml

<permissions>
    ...
    <securityProviders>
        <securityProvider class="com.ataccama.mda.core.config.security.MdaDefaultPermissionsProvider">
            <roles>
                <viewRoles>
                    <role name="MDM_viewer"/>
                </viewRoles>
                <userRoles>
                    <role name="MDM_user"/>
                </userRoles>
                <adminRoles>
                    <role name="MDM_admin"/>
                </adminRoles>
            </roles>
        </securityProvider>
    </securityProviders>
    ...
</permissions>

Deploy the updated file to the application server running the MDM Engine.

Configuring permissions

Double-click GUI Configuration and navigate to the Permissions tab. The following screen appears:
Specify the following:
- All Permissions: Grants permission for all entities and columns, including all actions.
  
  Use for development mode only.
- Default Permissions:
  - View Roles: Users with this role can see entities, workflows, and create tasks.
  - User Roles: Users with this role have all the View role permissions, plus the ability to edit records, create, discard, and delete tasks, and export data.
  - Admin Roles: Users with this role have all the User roles permissions plus the ability to publish tasks.
- Custom Permissions: Use if you need to configure custom permissions. See Configuring a custom permission scheme.
- Task Roles: Roles listed here are users to whom tasks can be assigned, as shown in the following example:

Configuring custom workflows

Configuring workflows consists of defining statuses and transitions between them.

When defining several workflows, it is possible to reuse statuses. However, one status is always shared - the status that starts the workflow.

Defining several workflows means that users will be able to choose the workflow when performing an action in MDM Web App.

To define a workflow:

Open the MDM Engine project in ONE Desktop.
Double-click the GUI Configuration project node. Select Workflow Configuration tab.
Under Statuses:
1. Define the statuses that the workflow will contain.
2. Make sure to select Enable for all of them.
3. Mark one of the statuses as First. This is the status with which the workflow starts.
Under Workflows:
1. Add a workflow Name and Label.
2. Make sure to select Enable.
3. Open the row detail and define all necessary Transitions between statuses.
Right-click GUI Configuration and select Generate. Now the mda-workflow.gen.xml file has been updated with the new configuration, and you can deploy it to the application server running the MDM Engine.

Prior to deploying a workflow change, we recommended processing all existing drafts (that is, either publishing or deleting all pending records). Otherwise, the workflow change might prevent MDM from starting after deployment.

In such cases, the MDM hub reports an error such as:

Starting the server with a changed workflow and existing drafts affected by the change.
NOTE: Before making changes to workflows, publish your drafts or make sure the drafts are not affected.

Configuring a custom permission scheme

Using GUI

Open the MDM Engine project in ONE Desktop.

Double-click GUI Configuration and navigate to the Permissions tab. First, clear the Default Permissions option.

It is possible to use both default and custom permissions, but if a role defined in the following steps in Custom Permissions has the same name as a Default Permissions role, it will be automatically overridden.

Select Custom Permissions and open Custom Permissions Settings by selecting the composite element link.
On the Roles screen that opens, select Add. Double-click the number next to the newly added role to define permission settings.
On the Role screen, define the following:
- Name: Name of the role.
- Description (optional): Description of the role.
- Configuring Workflows and Permissions: Workflow permissions, see Workflows. Includes permissions for Steps and Transitions.
- Instance layer: Instance layer permissions by entity. Includes Row permissions, Columns, and Steps.
- Master layer: Master layer permissions by entity. Includes Row permissions, Columns, and Steps.
- Datasets: Dataset permissions by entity. Includes Row permissions, Columns, and Steps.
  
  Select Enabled to enable every permission possible for the corresponding role.
  
  Use Fill Columns to quickly populate the Columns section with all available names.
Once you have filled all the necessary details, generate the project to save them. Right-click on GUI Configuration and select Generate.
Finally, in Keycloak, assign the newly created roles to Users as required.

Alternatively, all permissions can also be defined in mda-permissions.xml. See below for more information.

Workflows

Name: Name of the workflow. Steps: If a role contains a workflow step, the role can view drafts in this state. If the option is selected for that workflow step, the role can perform these actions on drafts in this step.

+ For example, if Publish is selected for that workflow step, the role can publish drafts in this state. For more information about workflows, publishing, discarding, and deleting drafts, see Publishing Workflow and Publishing Drafts. Transitions: If a role contains a workflow transition, the role can execute this transition (move drafts to another state).

Instance layer

Select All Entities to define the permissions for this role on all entities on the instance layer (this means that all attributes are generated as true, that is, enabled), or Add an entity, and double-click the number next to the added entity to define permissions.

The following screen appears:

Define the following:

Name: Name of the instance layer entity.
Create Issue(Boolean): If enabled, user can create issue items in this instance layer entity.
Export (Boolean): If enabled, a user can export items in the instance layer entity.
Row Permissions: Row permissions are defined using SQL WHERE conditions (supported operators and syntax depend on the database).

If an entity contains a row permission, the role can only view what is defined in the permission. If a role does not contain a row permission, it can see all rows.

If a user has more than one role, they have the row permissions of all assigned roles.
All Columns (Boolean): If enabled, applies Write, Override, and `Edit permissions to all columns in that instance layer entity for this role.
- Write: If enabled, a user can add items to this column on this instance layer entity.
- Override: If enabled, a user can override items on this column on this instance layer entity.
- Edit: If enabled, a user can edit items on this column on this instance layer entity.

Columns: define Write, Override, and Edit permissions on a column by column basis, for that instance layer entity for that role.

Override applies only to authored records (mixed style) and Edit applies to records from the consolidation model. If both Edit and Override are enabled, the Write attribute is automatically generated for that column.

Steps: Enable attributes for all defined steps by selecting the relevant option, or define Override, Ovr Active, and Ovr Match permissions on a step by step basis, for that instance layer entity for that role.
- Override: If enabled, the role can set and remove overrides on attributes (see Editing Values, section Editing consolidated values) for items in this step on this instance layer entity.
- Ovr Active: If enabled, the role can override the activity status of the record: set as active or inactive and remove activity overrides (see Activating and Deactivating Records) for items in this step on this instance layer entity.
- Ovr Match: If enabled, the role can merge master records, merge instances, and split instances (see Merging and Splitting Records) for items in this step on this instance layer entity.
  
  Permissions set in the Columns field must match those defined in the Steps field for that role, otherwise an error is thrown.

Master layer

Add a master layer, and double-click the number next to the added layer to define permissions.

The following screen appears:

Define the following:

Name: Name of the master layer.
All Entities: If true, permissions for this role apply to all entities on this master layer. Master Entities: To add permissions on an entity by entity basis, select Add and double-click the number next to the added entity. The following screen appears:

Define the following:

Name: Name of the master layer entity.
Create Issue (Boolean): If enabled, user can create issue items in this master layer entity.
Export (Boolean): If enabled, a user can export items on this layer.
Row Permissions: Row permissions are defined using SQL WHERE conditions (supported operators and syntax depend on the database).

If an entity contains a row permission, the role can only view what is defined in the permission. If a role does not contain a row permission, it can see all rows.

If a user has more than one role, they will have the row permissions of all assigned roles.
All Columns (Boolean): If enabled, applies Write, Override and Edit permissions to all columns in that master layer entity for this role.
- Write: If enabled, a user can add items to this column on this master layer entity.
- Override: If enabled, a user can override items on this column on this master layer entity.
- Edit: If enabled, a user can edit items on this column on this master layer entity.

Columns: Define Write, Override, and Edit permissions on a column by column basis, for that master layer entity for that role.

Steps: Enable attributes for all defined steps by selecting the relevant option, or define permissions on a step by step basis, for that master layer entity for that role. Different actions are available depending on whether records are authored or consolidated.
- For consolidated records, Override, Ovr Active, and Ovr Match are available.
  - Override: If enabled, the role can set and remove overrides on attributes (see Editing Values) for items in this step on this master layer entity.
  - Ovr Active: If enabled, the role can override the activity status of the record: set as active or inactive and remove activity overrides (see Activating and Deactivating Records) for items in this step on this master layer entity.
  - Ovr Match: If enabled, the role can merge master records, merge instances, and split instances (see Merging and Splitting Records) for items in this step on this master layer entity.
- For authored records, Master Edit, Master Create, and Master Delete are available. If enabled, the role can execute these actions on items in this step master layer (see Editing Values) for items in this step on this master layer entity.

If you add Master Create permission on the entity, make sure to add Write permission to all foreign columns on this entity. Missing Write permissions on foreign columns can cause exceptions in case you wish to create this entity from the parent entity in MDM Web App.

Permissions set in the Columns field must match those defined in the Steps field for that role, otherwise an error is thrown.

Datasets

Select All Datasets to define the permissions for this role on all datasets (this means that all attributes are generated as true, that is, enabled), or Add a dataset, and double-click the number next to the added dataset to define permissions.

The following screen appears:

Define the following:

Name: Name of the dataset.
Create Issue (Boolean): If enabled, user can create issue items in this dataset.
Export (Boolean): If enabled, a user can export items in this dataset.
Row Permissions: Row permissions are defined using SQL WHERE conditions (supported operators and syntax depend on the database).

If an entity contains a row permission, the role can only view what is defined in the permission. If a role does not contain a row permission, it can see all rows.

If a user has more than one role, they have the row permissions of all assigned roles.
All Columns (Boolean): If true, applies Write, Override, and Edit permissions to all columns in that dataset for this role.
- Write: If enabled, a user can add items to this column in this dataset.
- Override: If enabled, a user can override items on this column in this dataset.
- Edit: If enabled, a user can edit items on this column in this dataset.

Columns: define Write, Override, and Edit permissions on a column by column basis, for that dataset for that role.

Permissions set in the Columns field must match those defined in the Steps field for that role, otherwise an error is thrown.

Using XML

Open the MDM project in ONE Desktop.
Open Files > etc > mda-permissions.xml.
Make sure that only the <securityProvider class="com.ataccama.mda.core.config.security.MdaPermissionsProvider"> is enabled and all others are commented out.
Configure permission scheme according to your needs by following the sample configuration and guidelines below.

mda-permissons.xml with a custom permission scheme

<?xml version='1.0' encoding='utf-8'?>
<permissions>
...
    <securityProviders>
        <securityProvider class="com.ataccama.mda.core.config.security.MdaPermissionsProvider">
            <rolesBean class="com.ataccama.mda.core.config.security.MdaXmlRolesProviderConfig">
                <roles>
                    <role name="MDA_user">
                        <description>MDA user</description>
                        <workflows>
                            <workflow name="consolidation">
                                <steps>
                                    <step name="draft" discard="true"/>
                                    <step name="waiting_for_publish"/>
                                </steps>
                                <transitions>
                                    <transition name="move_publish"/>
                                </transitions>
                        </workflows>
                        <instanceLayer>
                            <entities>
                                <entity name="party">
                                    <steps>
                                        <step name="draft" workflow="consolidation" override="true"/>
                                    </steps>
                                    <columns>
                                        <column name="id" write="true"/>
                                        <column name="src_first_name" write="true"/>
                                        <column name="cio_gender"/>
                                    </columns>
                                    <row>cio_gender IN ('F', 'M')</row>
                                </entity>
                            </entities>
                        </instanceLayer>
                        <masterLayers>
                            <masterLayer name="masters">
                                <entities>
                                    <entity name="party" export="true">
                                        <steps>
                                            <step name="draft" workflow="consolidation" ovrMatch="true"/>
                                        </steps>
                                        <columns>
                                            <column name="id" write="true"/>
                                            <column name="cmo_first_name" write="true"/>
                                            <column name="cmo_gender"/>
                                            <column name="cmo_type"/>
                                        </columns>
                                        <row>cmo_gender = 'F'</row>
                                    </entity>
                                    <entity name="party_instance" createIssue="true">
                                        <steps>
                                            <step name="draft" workflow="consolidation" ovrMatch="true"/>
                                            <step name="waiting_for_publish" workflow="consolidation" ovrMatch="true"/>
                                        </steps>
                                        <columns>
                                            <column name="id" write="true"/>
                                            <column name="src_first_name" write="true"/>
                                            <column name="cio_gender" write="true"/>
                                            <column name="cio_type" write="true"/>
                                        </columns>
                                        <row>cio_type = 'P'</row>
                                    </entity>
                                </entities>
                            </masterLayer>
                        </masterLayers>
                        <datasetLayer>
                            <entities>
                                <entity name="party_contact_inst" createIssue="true">
                                    <columns>
                                        <column name="id" write="true"/>
                                        <column name="party_instance_std_first_name" write="true"/>
                                    </columns>
                                    <row>party_instance_std_first_name NOT IN ('John', 'Jordan')</row>
                                </entity>
                            </entities>
                        </datasetLayer>
                    </role>
                    <role name="MDA_superuser">
                        <description>MDA superuser</description>
                        <workflows>
                            <workflow name="consolidation">
                                <steps>
                                    <step name="draft" discard="true"/>
                                    <step name="waiting_for_publish" discard="true" publish="true"/>
                                </steps>
                                <transitions>
                                    <transition name="move_publish"/>
                                    <transition name="return_draft"/>
                                </transitions>
                            </workflow>
                        </workflows>
                        <instanceLayer>
                            <entities>
                                <entity name="party" createIssue="true" export="true">
                                    <steps>
                                        <step name="draft" workflow="consolidation" override="true"/>
                                        <step name="waiting_for_publish" workflow="consolidation" override="true"/>
                                    </steps>
                                    <columns>
                                        <column name="id" write="true"/>
                                        <column name="src_first_name" write="true"/>
                                        <column name="cio_gender" write="true"/>
                                        <column name="std_gender" write="true"/>
                                    </columns>
                                    <row>std_gender NOT IN ('m0', 'f1')</row>
                                </entity>
                            </entities>
                        </instanceLayer>
                        <masterLayers>
                            <masterLayer name="masters">
                                <entities>
                                    <entity name="party" createIssue="true" export="true">
                                        <steps>
                                            <step name="draft" workflow="consolidation" ovrMatch="true" override="true"/>
                                            <step name="waiting_for_publish" workflow="consolidation" ovrMatch="true" override="true"/>
                                        </steps>
                                        <columns>
                                            <column name="id" write="true"/>
                                            <column name="cmo_first_name" write="true"/>
                                            <column name="cmo_gender" write="true"/>
                                            <column name="cmo_type" write="true"/>
                                        </columns>
                                        <row>cmo_gender = 'F' OR cmo_gender = 'M'</row>
                                    </entity>
                                    <entity name="party_instance" createIssue="true">
                                        <steps>
                                            <step name="draft" workflow="consolidation" ovrMatch="true"/>
                                            <step name="waiting_for_publish" workflow="consolidation" ovrMatch="true"/>
                                        </steps>
                                        <columns>
                                            <column name="id" write="true"/>
                                            <column name="src_first_name" write="true"/>
                                            <column name="cio_gender" write="true"/>
                                            <column name="cio_type" write="true"/>
                                        </columns>
                                        <row>cio_type = 'P'</row>
                                    </entity>
                                </entities>
                            </masterLayer>
                        </masterLayers>
                        <datasetLayer>
                            <entities>
                                <entity name="party_contact_inst" createIssue="true">
                                    <columns>
                                        <column name="id" write="true"/>
                                        <column name="party_instance_std_first_name" write="true"/>
                                    </columns>
                                    <row>party_instance_std_first_name NOT IN ('John', 'Jordan')</row>
                                </entity>
                            </entities>
                        </datasetLayer>
                    </role>
                </roles>
            </rolesBean>
        </securityProvider>
    </securityProviders>
</permissions>

Workflow permissions

If a role contains a workflow status, the role can view drafts in this status.
If a role contains a workflow transition, the role can execute this transition (move drafts to another status).
If a status contains the attributes discard="true" or publish="true", the role can discard/publish drafts in this status.

Entity permissions

Entities include the tables on instance and master layer, reference data tables, and data sets.

If a role contains an entity, the role can view the entity.
If an entity contains the attribute createIssue="true", the role can create issues on this entity.
In an entity contains the attribute export="true", the role can export data from this entity.
If an entity contains a status (identified by the status name and the workflow name), the role can execute actions. The following actions can be specified ([action]="true"):
- override: Set and remove overrides on attributes.
- ovrMatch: Merge master records, merge instances, and split instances.
- ovrActive: Override the activity status of the record: set as active/inactive and remove activity overrides
If an entity contains columns, the the role can view these columns.
If a column contains the attribute write="true", the role can override/edit this value if the workflow status allows this action.

Row permissions

If a role does not contain a row permission, it can see all rows.
If an entity contains a row permission, the role can only view what is defined in the permission.
Row permissions are defined using SQL Where conditions.
- Supported operators and syntax are dependent on the database.
If a user has more than one role, they will have the row permissions of all assigned roles.

Row permissions example

<!-- Role has permission to view column cio_gender if the values are 'M' or 'F' -->
<row>cio_gender IN ('F', 'M')</row>

<!-- Role has permission to view records which have a first name column containing the letter 'a', gender column containing the value 'M' or an ID value less than 2000.  -->
<row>(first_name LIKE '%a%' AND gender = 'M') OR id &lt; 2000</row>

For example, to see only gender = M records in Party entity, the mda-permissions.xml would be as follows:

<entity name="party" >
     <columns>
         <column name="src_first_name" write="true"/>
         <column name="src_last_name" write="true"/>
         <column name="src_gender" write="true"/>
     </columns>
  <row> src_gender = 'M' </row>
 </entity>

Was this page useful?