MM 6.1 Setting up user approval workflow

Roles

For the roles required to configure workflows and automations, please refer to: https://digizuite.atlassian.net/wiki/spaces/DD/pages/3804632888/DC+6.0+Roles?search_id=dcfa6401-e0d3-424c-ab65-875cc6d032e7.

User approval workflow simplifies the process of approving new users when self-sign-up is enabled, as well as enables the creation of custom sign-up forms.

An example of a correctly configured approval flow presented here consists of three parts. In the first stage, the administrator configures the user approval workflow. It is here where the custom sign-up form can be built, dependent on the needs of the organization. The second stage is an automation, which converts the approved cases into actual system users. In the last stage of the process, the administrator enables the functionality in the system.

The following elements are required for a functional approval process:

  • A workflow with the minimum of three stages: a pending stage, an approved stage and a rejected stage

  • An automation based on the “Business Workflow Stage Entered” trigger

  • Enabling the self-sign-up in the Media Manager.

  • The guest user has the role: Business_Workflow_View or Business_Workflow_Instance_View (or Business_Workflow_CRUD, but this is not recommended)

Part 1 Workflow

The core part of the flow is setting up the workflow. It is in here that a system administrator can add new fields to the custom sign-up form and decide who should be responsible for approving new accounts.

stage "pending_approval" { type = "Manual Stage" label = "Pending approval" row = "1" column = "1" description = "" retired = "false" automatically_assigned_to = "groupId:2" icon = "yellow-activity" } transition "sign_up" { type = "Manual Transition" label = "Sign up" to = "pending_approval" constraints = ["constraint_1", "constraint_5", "constraint_2", "constraint_3"] } stage "approved" { type = "Manual Stage" label = "Approved" row = "2" column = "0" description = "" retired = "true" icon = "green-checked" } transition "approve" { type = "Manual Transition" label = "Approve" from = "pending_approval" to = "approved" constraints = "constraint_4" } stage "rejected" { type = "Manual Stage" label = "Rejected" row = "2" column = "2" description = "" retired = "true" icon = "red-close" } transition "reject" { type = "Manual Transition" label = "Reject" from = "pending_approval" to = "rejected" constraints = "constraint_6" } constraint "constraint_1" { type = "Any user can transition" label = "Any user can transition" } constraint "constraint_5" { type = "String Input Constraint" key = "supervisor" label = "The name of your supervisor" tooltip = "Who is your supervisor?" placeholder = "Type your answer here" render_type = "text" promoted = "true" } constraint "constraint_2" { type = "Date Input Constraint" key = "signup_deadline" label = "When do you need the access to the system by?" tooltip = "Choose the deadline." placeholder = "Date" promoted = "true" } constraint "constraint_3" { type = "String Input Constraint" key = "use_type" label = "How will you primarily use the system?" tooltip = "E.g. uploading assets, content management." placeholder = "Type you answer here" render_type = "textarea" promoted = "true" } constraint "constraint_6" { type = "Only Current Stage Owner Can Transition" label = "Allow the assignee to transition" negate = "false" } constraint "constraint_4" { type = "Only Current Stage Owner Can Transition" label = "Allow the assignee to transition" negate = "false" }

Configuration:

Step

Configuration

Explanation

Step

Configuration

Explanation

“Sign up” transition

Name: selected by the user

Transition type: Manual

Unique ID: selected by the user

Description: selected by the user (optional)

Constraints: execution condition and input constraints

This is the first transition of the workflow, triggered by submitting of a new sign up form.

The transition is manual, because it is initiated by a deliberate action from a user - in this case, the act of submitting of a sign up form by a new user.

It is in this transition where the administrator can create a custom sign up form. Any information that should be provided in that form aside from the standard fields (such as name or password), can be configured here with the use of input constraints. In this specific example, the user will be asked, among others, to:

  • provide the name of the supervisor (String Input Constraint, rendered as text)

  • clarify how they will use the system (String Input Constraint, rendered as text area)

  • state when they need to have an active account by (Date Input Constraint).

Additionally, “Any user can transition” constraint was configured so that anyone can trigger the workflow by signing up.

“Pending approval” stage

Name: selected by the user

Unique ID: selected by the user

Description: selected by the user (optional)

Mark as completed: no

Relevant Meta Fields: -

Stage owner: Stage Assignment Behavior - Assign to a group

Labels: selected from the list of created as custom

The name of the stage is also the name of the task.

The optional description will provide the assigned user with the explanation of what is expected in this stage.

In this case, the stage owner is a user group. It means that any user belonging to that group can transition the task. i.e. approve or reject the new user.

The label will be displayed on the task.

“Approve” transition

Name: selected by the user

Transition type: Manual

Unique ID: selected by the user

Description: selected by the user (optional)

Constraints: execution condition

The manual transition means that the task can only be fulfilled by selecting one of the options from the list of available actions.

Constraint:

  • “Allow the assignee to transition” means that only the user(s) assigned to this task can either approve the new user.

“Approved” stage

Name: selected by the user

Unique ID: selected by the user

Description: selected by the user (optional)

Mark as completed: yes

Relevant Meta Fields: -

Stage owner: Unassigned

Labels: selected from the list of created as custom

The name of the stage is also the name of the task.

The optional description will provide the assigned user with the explanation of what is expected in this stage.

The label will be displayed on the task.

Marking the stage as complete means that the this particular workflow instance will be archived after this stage.

“Reject” transition

Name: selected by the user

Transition type: Manual

Unique ID: selected by the user

Description: selected by the user (optional)

Constraints: execution condition

The manual transition means that the task can only be fulfilled by selecting one of the options from the list of available actions.

Constraint:

  • “Allow the assignee to transition” means that only the user(s) assigned to this task can reject the new user.

“Rejected” stage

Name: selected by the user

Unique ID: selected by the user

Description: selected by the user (optional)

Mark as completed: yes

Relevant Meta Fields: -

Stage owner: Unassigned

Labels: selected from the list of created as custom

The name of the stage is also the name of the task.

The optional description will provide the assigned user with the explanation of what is expected in this stage.

The label will be displayed on the task.

Marking the stage as complete means that the this particular workflow instance will be archived after this stage.

Part 2 Automation

The next part is about setting up an automation for manifesting the approval workflow, converting the approved sign-ups into actual users.

When a user has been approved in the workflow, the user in the system behind is not impacted. This requires what we call an “automation”.

Below is an image of such an automation:

trigger "Business Workflow Stage Entered" { type = "Business Workflow Stage Entered" resolves = "ForEach" workflow = "Sign-up/user creation" stage_name = "approved" } foreach "ForEach" { type = "ForEach" resolves = "Approve Member" variable = "@sourceItemIds" as = "@sourceItemId" } action "Convert Member Item Id To Member Id" { type = "Convert Member Item Id To Member Id" needs = [] member_item_id = "@sourceItemId" member_id = "@memberId" } action "Approve Member" { type = "Approve Member" needs = "Convert Member Item Id To Member Id" member_id = "@memberId" approved = "true" }

Please note that the foreach is needed as newer iterations of automation only handle lists. This will ensure that your DSL will handle lists of members - to assets for that matter - in the future.

Configuration:

Step

Configuration

Explanation

Step

Configuration

Explanation

Business Workflow Stage Entered

Input(s)

Workflow: Select the correct user workflow from the dropdown list

Stage Name: Select the approved stage from that workflow from the dropdown list

Here, the administrator should indicate the preciously configured user approval workflow and then select at which stage the new user are approved, and therefore this automation should be triggered.

Convert Member Item Id To Member Id

Input(s)

Member Item Id: @sourceItemIds

Output(s)

Member Id: @memberId

Convert Member Item IDs into Member IDs.

A requirement for the next step as it only accepts Member IDs.

Approve Member

Input(s)

Member Id: @memberId

Approved: Checked

The newly created user is approved in the DAM Center and therefore can log in and start using the system.

It is also recommended to set up a custom e-mail notification to the new user once they have been approved. For more information on how to create e-mail templates and how to configure sending them using automations, please refer to https://digizuite.atlassian.net/wiki/spaces/DD/pages/3804631354/DC+6.0+Example+-+Sending+emails.

Part 3 Additional configuration in the Media Manager

In order for the user approval workflow to work, self-sign-up must be enabled. This will enable new users to sign up for the system. This can be done selecting AdministrationPortals → <portalname> → Configuration → Security

Another relevant field is the Self Signup Template. The administrator can create a user template and then select it in Administration → System → Services → User Management. All the users approved through the workflow will receive a set of roles that come with that template user by default. It is possible later on to manually add and remove roles from the new user.

If no further action is taken, the sign-up process will be generic and automatic. This is why another step is required: enabling the user approval workflow in the Media Manager. This can be done selecting AdministrationPortals → <portalname> → Configuration → Security, and then selecting the correct workflow from the dropdown list.