 Welcome to BMC Video Solutions. In this video, we will introduce the Control-D Report Approval feature. The Report Approval feature enables the implementation of an approval and workflow process for reports in the Control-D repository. The Report Approval feature is useful for preventing reports from being published before they are approved. It is also useful for facilitating a workflow process. Typically, reports are distributed to recipients specified in the declaration mission. These recipients can view the reports through Control-D Web Access. If an approval workflow is required, specify the approval option in the declaration mission. When the approval option is activated, end user recipients can only see the report in Web Access after the report has been approved by the Approver recipient. Now let's see how a report is approved. Open Web Access in your browser. The report list displays all your reports. In the Filter Report List dialog, choose Reports for Approval. The report list is now called Approvals, displaying only the reports that need approval. Open the report you want to review. If the report is OK, choose Approve from the Report menu and enter a comment in the message box. The report can now be viewed by other users. Now let's see how the Report Approval feature is implemented. To implement the Report Approval feature, the Control-D Administrator must first define Approval Profiles. Each profile includes a group of one or more Web Access users that are responsible for approving reports. When a report requires an approval workflow, the Administrator must assign the report to a specific Approval Profile. The Approval Profile is defined in the Approval Definition panel. Let's go to the T-Screen to see this panel. From the IOA Primary Option menu, enter T. The IOA Recipient Approval Tree entry panel opens. To open a tree, type in a tree member name. The Control-D Recipient Approval Tree panel opens showing the contents of the tree member. Each tree member can contain one or more Approval Group Profile definitions. In this example, there are three definitions. Let's open an Approval Definition. We can identify an Approval Profile by the name in the Approval field. We can create a group of approvers by entering their Web Access user IDs in the Authorize fields. We can determine the relative position of this Approval Profile in the Approval Hierarchy by specifying the appropriate number in the Approval Level field. The Parent Approver name and level is also indicated. The Parent Approver must approve the report before the current approver can view their report. Lines of description can also be added, including email addresses for notification that the report needs approval. Let's go back a second. Note that when creating a new Approval Tree member, the Administrator must use the keyword CD-APPROV as the first or root parent Approval Profile Definition name. Using any other name for the root parent profile definition, we'll open a recipient definition panel instead of an Approval Definition panel. And this is not what we want now. Instead, we need an Approval Profile. Once we have created an Approval Profile, we are ready for the next step. When a report requires an Approval Process, the Administrator opens the report's Decoration Mission to assign the report to an Approval Profile using the Do Approve parameter. Let's go to the R screen and open a Decoration Mission to see an example of a Do Approve parameter. The first field is the Approval Name. This is the name of the Approval Profile definition that we defined in the Approval Tree member. When Y is entered in the Hidden field, the report is hidden from all users except the Approvers specified in the Approval Profile definition. These are the Web Access users specified in the Authorize fields. When S is entered in the Multifield, the Approval is relevant to more than one report. The Approval is defined for a specific report, but applies to all reports related to the same SIS out. When Y is entered for the Store field, the Approval Process is activated only for the report created by the Print Mission with Store equals Y. With the default N, the Approval Process is activated only on the Decolated report. Finally, to enforce a Service Level Agreement, the number of days after the report is generated that the report must be approved is entered in the SLA field. When we run the report's Decolation Mission, the Approval Process will take effect for this report according to how we defined the Do Approve parameter. Let's summarize the Report Approval Process. First, the Report Approval Workflow must be implemented by defining an Approval Profile definition in an Approval Tree and by assigning the Report to the Approval Profile using the Do Approve parameter in the Decolation Mission. Next, we must run the Decolation Mission. Finally, the Report can be approved in Web Access.