...
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.
...
Expand | |||||
---|---|---|---|---|---|
| |||||
|
Configuration:
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:
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:
|
“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:
|
“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 user systems in the DAM Center.
...
Info |
---|
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 |
---|---|---|
Business Workflow Stage Entered | 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 Id To Member Item Id | Inputs: Member Item Id: @sourceItemIds Outputs: Member Id: @memberid | Member Item Ids are converted into Member Ids, necessary for the approval process. |
Approve Member | 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 DC 5.5 Example - Sending emails.
...