ONE Desktop ONE DQ&C ONE MDM ONE RDM ONE Runtime Server
latest (15.3.0) 15.2.0 15.1.x 14.5.x 13.9.x 13.8.x 13.7.x 13.6.x 13.5.0 13.4.x 13.3.x 13.2.x
User Community Service Desk Downloads
If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

Configuring RDM Workflows

Workflows in RDM allow you to track changes made to a record in the web application and make sure all necessary parties approve or further edit the record before publishing it. It is possible to configure email notifications to inform relevant parties that they need to take action to move the record in the editing workflow.

Workflows are defined separately for each table, which allows you to create custom workflows for every individual table.

Workflows are configured in the Workflows and Notifications node of the RDM project.

How workflows in work in RDM?

In the context of RDM, a workflow is a process that starts with making changes to the data and ends with publishing them. These two points are represented in RDM with two record states:

  • Edited - A state after a record has been created, modified, or deleted.

  • Published - A state after the record has been published.

Each record goes through these two states. For further control and additional input, you can model custom workflows for each table per particular action (create, edit, delete).

Such workflows place additional states between the basic ones mentioned previously. During each state, all assigned users approve the changes made, fill in the necessary attributes, and advance the record to its next state.

Example workflow

In the RDM model project, record states are modeled as Statuses. The first step is Edited and the last step is Published. Other statuses are named as Custom steps.

See web-application:moving-records-through-RDM-workflows.adoc for the web application perspective on workflows.

Statuses

Statuses are reusable abstract steps that compose workflows and reflect the state of the record as discussed in previous sections. Statuses themselves do not carry any particular function apart from being containers for steps in different workflows (statuses are defined just by label).

To see how statuses are reusable, think of a status called Fill in. Such a status can be used in different workflows for the same table or even in different tables:

  • In workflow 1, it might mean filling column A and B by a user with the Supervisor role.

  • In workflow 2 in a different table, it might mean filling column C and D by a user with either the Developer or Administrator role.

  • Furthermore, in workflow 1, the Fill in step might be followed by the Approve step while in workflow 2, this would be the last necessary step before publishing the record.

So the general purpose of the Fill in status is to be used in a workflow, which, among other things, requires its participants to fill additional information in some of the workflow steps. The actual columns to be filled and other conditions are configured inside the step to which the status is mapped.

You can also use a completely different set of statuses for each workflow, but it might mean unnecessary double work.

Create a new status

  1. Right-click Statuses > New status.

  2. Fill in Label. This is the name of the status that is displayed in the RDM web application in the [ State ] column and Workflow state field of record details.

  3. Select OK to save changes.

Now the status can be used in workflows.

Configure a workflow for a table

Create statuses

Make sure you have created all the statuses you need for the workflow. You need as many statuses as there are approval stages the record passes before it is ready to be published, plus two technical statuses representing:

  1. A record in the Edited state (the first state before the record enters the workflow).

  2. A record in the Published state (the step into which the record exits the workflow).

Select a table

Workflows are defined separately for each table, therefore you need to select one of the tables defined in the RDM Logical Model > Tables node:

  1. Go to Workflows and Notifications > Tables (right-click) > New table.

  2. Select a table (press Ctrl+Space) in the Table name attribute on the General tab.

Select a table
Table name

Create a new workflow

  1. Switch to the Workflows tab.

  2. Select Add (1) to add a new workflow, then double-click the first row (2) to enter the workflow details.

    Create a new workflow

  3. In Edit operation, define the type of action that starts the workflow. Possible options are: Create, Delete, Update.

Add approval steps

The Edited and Published steps are preconfigured and appear in special fields when you are creating record workflows. To define the actual steps of your custom workflow:

  1. Add a step and double-click the first Step row to enter the details. Press Ctrl+Space to select from available statuses.

    Add approval steps

  2. Define the step logic on the General tab and specify:

    1. General step characteristics and conditions.

    2. Statements.

    3. Notifications.

  3. Switch to the Columns tab and specify which columns can be modified in this workflow step by step participants. Apply changes and go back to define the next workflow step.

  4. Repeat this step after you have configured all approval steps for this workflow.

General step characteristics and conditions

Name Required Description

Condition

N

The condition that the record must satisfy to enter the step. If the record does not satisfy the condition, it is automatically moved to the next step.

The condition uses Ataccama ONE expression syntax. See ONE Expressions.

TIP: In addition to using standard business attributes in the condition, you can also use usernames. For example, you can let some users skip all or some of the workflow steps by defining a condition as follows: meta.username <> 'admin'.

Expires after (days)

N

After the specified number of days, the workflow automatically moves to the next step.

Transition label

N

Label of the transition used in the workflow diagram (see Open the workflow diagram). It is filled after consequent steps are added, see Connect the steps and add transition labels.
General configuration

Statements

The number of configured statements corresponds to the number of approvals that are required to move a record to the next step, provided that all conditions are satisfied.
Name Required Description

Condition

N

Only records satisfying this condition are available for approval to users with the roles attribute. The condition uses Ataccama syntax. See Commonly Used Functions.

Email notification

N

A previously defined email template to be sent when a record arrives to the current step.

Roles

N

Allows adding roles required to approve the record and move it to the next workflow step (users with these roles receive an email notification).

Name

N

A user with at least one of the roles listed in this column has to approve the change to move the record to the next workflow step.
Statements

Notifications

Name Required Description

Email notification after finishing the step

N

A previously defined email template to be sent when a record moves to the next step.

  • Email notification - Email template to be sent.

  • Roles - Roles to which the email is sent.

Reject email notification

N

A previously defined email template to be sent when a record is rejected in the current step (and moved to the previous step).

  • Email notification - Email template to sent.

  • Roles - Roles to which the email is sent.

Connect the steps and add transition labels

Go back to the created steps and connect them with each other by filling in the Transition label attribute (optional). You can then control the workflow order by opening its diagram, as shown in the following section.

Open the workflow diagram

The workflow diagram lets you view the graphical representation of the workflow and get a complete overview of the workflow.

Opening the workflow diagram

Was this page useful?