 Welcome to VMC's Control-D Report Multi-Approval video. In this video, you will learn about assigning reports for approval by multiple groups of authorized users, also known as multi-approval. We will demonstrate two modes of multi-approval, parallel approval, multi-level approval. If you haven't seen our Control-D Introduction to Report Approval video, we recommend that you view that video first. Reports are distributed to recipients specified in the Decalation Mission. These recipients can view the report through Control-D Web Access. You can decide that after a report is generated, it must first go through an approval process. You can require that multiple approvers review the report, either in parallel with no dependencies between approvers, or as a hierarchical multi-level process where each approver must wait for the previous approver. To implement an approval process with several approvers, you must perform several tasks. First, configure multiple approvers in the approval tree. This is done by the administrator. Next, specify an approval name in the Decalation Mission. This too is done by the administrator. Next, run the Decalation Mission. This generates a report in the Control-D repository. Finally, as an approver, access the report through Control-D Web Access and approve or reject the report. Let's take a look at how to perform these tasks for parallel approval and multi-level approval. Let's start with parallel approval. Our first task is to configure the approval process in the approval tree. Let's go to the recipient slash approval tree, option T. In the entry panel, we'll specify the name of an approval tree member. We'll use the sample approval tree provided in Control-D, member CTD, APRV. The root level element in an approval tree is always CDApprove. Each approval element authorizes one or more users or groups to approve the report. At least one of the users defined in these authorized fields will need to approve the report. Here, we have a group of nodes for parallel approval. That is, several approval elements that are responsible for prompting multiple approvers to approve a report in parallel. The parent node named par-app is not associated with any users in its authorized fields. Underneath this parent node, we see two approval elements, par-1 and par-2, each associated with two users. We will now associate our parallel approval element with a report. Let's go to the report-decolating mission definition entry panel, option R. Here, we will enter the definitions of a report that I have prepared to demonstrate parallel approval, a report named par-app. In this report, the do-approve option specifies the par-app approval, which we just saw defined in the approval tree. Now, when we run the declaration mission, the report is created in the Control-D repository and is ready for approval. Approvers view reports in Control-D web access. Here, they approve or reject the reports that were assigned to them. Here are two web access sessions. I logged on to one of these sessions as user U05A from the first approval element, par-1, and I logged on to the other session as user U05B from the second approval element, par-2. Click Filter to open the Filter Report List dialog box and select Reports for Approval. In the sessions of both users, we see the Approval Example 2 report. Note the status of the report. There are no dependencies between the approvers, and they can approve the report in any order. We'll start with U05B. Hover over the report and click Open Report. After reviewing the report, go to the Report menu and choose either Approve or Reject. We will now approve the report. Now, use U05A. We review the report and approve it. The status of the report has changed to Approved. As long as the report is in the active user file, any of the approvers can reject a report that was already approved, or approve a report that was already rejected. Now, let's show the process for multi-level approval. Our first task is to configure the approval process in the Approval Tree. In the same approval tree, we have a group of nodes for multi-level approval. The ML App and ML App 2 approvals are organized hierarchically. The first level approver must approve the report first, and only then the second level approver is prompted to approve the report. Each of these approvals is associated with one user. We will now associate our multi-level approval element with a report. Let's go into the report-decolating mission definitions of a report that I have prepared to demonstrate multi-level approval, a report named ML underscore app. In this report, the Do Approve option specifies the ML App approval, which we just defined in the approval tree. Now, when we run the declaration mission, the report is created in the Control-D repository and is ready for approval. Again, I have two sessions in Control-D web access. One for user U05A from the first level approval element, ML App, and the other for user U05B from the second level approval element, ML App 2. For U05A, we see that Report Approval Example 1 is ready for approval. Note the status of the report. U05B has not yet been prompted to approve this report. This user will be prompted to approve the report only after it is approved by user U05A. Let's start with the first level approval represented by user U05A. Hover over the report and click Open Report. After reviewing the report, go to the Report menu and choose Either Approve or Reject. We will now approve the report. After the report was approved by the first approver, it is available for approval by the second approver, represented by user U05B. Through the report menu, user U05B can now select Either Approve or Reject. The status of the report has changed to Approved. As long as the report is in the active user file, the last approver can reject a report that was already approved, or approve a report that was already rejected. Thank you for watching this video. For more information about Control-D Report Approval, watch the Control-D Introduction to Report Approval video, or read the Control-D Help End documentation.