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 tasks. A task 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 folloeing 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.gen.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.gen.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.
  
  Assigned Group and User Assignee are a group of people or one person to which the task is automatically assigned for a specific transition.
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 tasks (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 tasks affected by the change.
NOTE: Before making changes to workflows, publish your tasks or make sure the tasks are not affected.

Configuring a custom permission scheme

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.
Can create task: Specifies if the user with this role can create tasks.

Can manage automated task (only for admin role): Specifies if the user with this role can manage automatic tasks.

Users with automated task creation permissions must also have view permissions for all entities and columns that are used in the automatic tasks they created. Otherwise, these users cannot view the task detail.

Can manage AI matching: Specifies if the user with this role can manage AI matching.

Users that train AI or review training must have full view permissions on the training entity both for columns and rows. The absence of column permissions can cause inadequate matching decisions, and the absence of row permissions can result in error.

Workflows: Workflow permissions. 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.
Matching proposal layer: Matching proposal permissions by entity. Includes view and reject permissions.

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.

Workflows

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

+ For example, if Publish is selected for that workflow step, the role can publish tasks in this state. For more information about workflows, publishing, discarding, and deleting tasks, see Publishing Workflow and Resolving Tasks. Transitions: If a role contains a workflow transition, the role can execute this transition (move tasks 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.
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.
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 editing-master-data:merging-and-splitting-records.adoc[]) 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.
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.

Matching proposal layer

On this level, you can define view and reject permissions for matching proposals for the role.

All Entities: If true, permissions for this role apply to all entities on this master layer.
Matching proposals: To add entities, select Add and provide the following:
- Name: Name of the matching proposal entity that the user with this role role can view.
- Reject: Specifies if the user with this role can reject matching proposals on this entity.
  
  Alternatively, you can specify the entity name and reject rights by double-clicking the number of the row, which opens the following window:

Was this page useful?