Working with Requests

Change Requests

A change request can be submitted by a governance user who has Submit access to both a data set and a workflow model that is configured to be used with the data set. Users who are granted Submit access to data and a workflow model are typically the users who will be initiating change requests for that data to be governed using that model.

Remediation Requests

Remediation requests are used to initiate some corrective action to be taken by another user. A remediation request can be submitted by any interactive user who also is a governance user and has been granted Read interactive access and Submit workflow access to a data set and a workflow model. A remediation request is typically created from the results of another operation such as a batch validation, query, or comparison. Nodes from those results can be added to a remediation request using the node Clipboard.

Request Items

Request items are used to perform workflow tasks within the context of a governance request. Each request item uses a single workflow task which must be specified when the item is added to a request. The workflow task defines the types of changes to be performed for a hierarchy node in the Data Relationship Management version used by the request.

A request may consist of one or more request items. During Submit or Enrich workflow stages, new request items can be added to a request to perform new tasks. During Enrich stages, request items added in previous stages can be modified or overridden using an Update task assigned to the workflow stage.

Request items can be added manually or loaded from a source file. The order of request items in a request is important because it controls the order that the changes in the request get applied to the target version for validation and commitment purposes.

Request items can only be deleted during workflow stages which have a matching workflow task to the request item.

Creating a Source File

You can add items to a request from a source file. Items are loaded to the current workflow stage, for a single hierarchy and workflow task.

Source files must be in a tabular, delimited format. The first record in the file is used to identify the request item property to which each field will be loaded. Only editable properties for the selected workflow task will be loaded from the file. Fields which are not mapped to editable properties for the request item will be ignored during the load. The Name property is required for every request item loaded from a source file.

Some guidelines for creating a request item source file are:

For Insert tasks, Name is the node to be inserted, Parent Node is the target parent, and the hierarchy you select in the Load Request Items dialog box is the target hierarchy.
You can specify all data values for a request item in separate fields of the same record in a flat file.
You must define which fields in the file correspond to which properties of the workflow task for a request item using column header record in the file (using property labels).
You can specify property labels for workflow task properties in the column header record in any order.
The property label match is case-insensitive.
The Name property is required for all records in source file.
Any editable property for the selected workflow task can be loaded from a source file.
Columns where header record value does not map to an editable property for the workflow task will be ignored during the file load process.
Use a blank value for a field where you do not want to supply a value for the property. In cases where you want to override a property with a null value, use the Blank Value Indicator option when loading the file.
If a task property is defined with a custom property label, then use the same custom field label in the file.

Source File Example

#New Financial Accounts
Name,Parent Node,Description,Account Type,Start Date,End Date,Allow Posting
6000,5000,Total Employee Expenses,Expense,,,N
6200,6000,Compensation Expenses,,,,N
6210,6200,Vacation Paid,,1/1/2015,12/31/2015,Y
6220,6200,Employee Benefits,,1/1/2015,<blank>,Y

Item Details

Property details are displayed for a selected request item in a request. The properties which are available for display and edit are controlled by the workflow task for each request item or the task for the current workflow stage. For request items where new hierarchy nodes are being created, a single column of proposed new values is displayed. For request items which refer to existing hierarchy nodes, two columns of values (Current and New) are displayed. The Current Values column displays existing property values while the New Values column displays changed property values. Modified properties are marked for easy identification. Calculated property values are displayed as read only. Properties are tagged with validation failures for quick resolution. To remove a property update from a request item, click the Revert to Previous Value link.

Renaming Request Items

You can rename a request item using the Rename link provided under the Name property in the request item details. The rename feature changes the name of the request item and synchronizes the new name to other request items which refer to it as a parent or use a node data type property. You can rename a node at any workflow stage where the Name property is editable.

Note:

If you want to change the node name back to the original name, use the Rename link and re-enter the previous name. The Revert to Previous Value button is not available for the Name property.

Task and Property Instructions

Instructions for request items can be viewed on the Request page. Instructions may be defined for workflow tasks and their properties. In the instructions area, you can view the instructions defined for the request item task. You can choose to show or hide the task instructions. In the Item Details section, you can view instructions defined for properties of the request item task. Instructions are displayed above the request item property value.

To view task and property instructions:

From the Worklist, select a request and open it.
Select a request item to view details of the item.
In the Instructions area, view the instructions defined for the task.

Note:

You can click Hide to hide the task instructions. If the instructions are hidden, click to show them.
In the Item Details section, view Property instructions which are displayed above the property field.

Request Actions

When you are working with a request, action buttons in the upper right corner of the page header allow you to perform actions on the request. Certain actions will only be available depending on the situation. The following table describes the actions and provides the corresponding action button.

Table 8-1 Action Buttons

Action Button	Description
Save	Saves the request to the Data Relationship Management repository in its current state without validating or approving the request This action is available for new requests and claimed requests.
Export to Excel	Exports the request items in an Excel (.xls) format.
Export to CSV	Exports the request items in an Comm-separated (.csv) format
Submit	Validates the request items in the request and if successful, assigns the request to the next stage in the workflow path This action is available for draft requests or requests that have been pushed back to the submitter.
Calculate	Calculates request item details based on proposed changes in the request
Validate	Validates proposed changes for request items in the request This action checks required values and runs batch validations configured for the task for the request item or the current workflow stage. Validation failures are returned for correction. Requests can be validated if: The request is in the Draft workflow status and has at least one request item The request is in the Claimed workflow status
Copy	Copies request items to a new request To copy a request, you must have access to submit the type of request you have selected.
Claim	Claims the request for the active workflow stage. A submitted request can be edited, pushed back, escalated, approved, or rejected only by a user who has claimed the request. When a user claims a request, the request is locked and cannot be claimed by any other user. The user must unclaim the request to release it to be claimed by another user.
Unclaim	Removes the claimed lock from the request but does not validate or assign the request to a different stage, user, or group If a user chooses to push back, escalate, approve, or reject the request, the request is automatically unclaimed.
Pushback	Pushes back the request to a previous user in the current stage or a previous stage to correct some element of a request or ask for more information about the request The user pushing back the request must provide a comment about why the request has been pushed back.
Escalate	Escalates the request to Data Manager role users Users may escalate a request for any number of reasons; for example, if they are unsure about what to do with a request or if they have access issues. Data Managers may resolve issues by adding comments to the request, changing the request items, modifying node access group assignment to hierarchies and nodes, or rejecting the request.
De-escalate	Reassigns the request to the next node access group for the current workflow stage
Approve	Approves and commits the changes in the request to the target version
Reject	Rejects the request A submitted request may be rejected by any approving user in the workflow path or a Data Manager during escalation. Rejecting a request terminates the workflow for the request. A rejected request cannot be resubmitted. To resubmit the request items in the rejected request, the original submitting user or another Submit stage participant can copy the rejected request to a new draft request, edit the request items in the new request, and then submit the new request.

Request Comments

Comments entered by participating users of a request can be viewed on the Comments tab. Assigned users can add new comments as needed.

To add a comment to a request:

Open a request from the Worklist.
On the Comments tab, click , enter a comment, and then click OK.

Request Attachments

Users who are creating a draft request or who have claimed a submitted request can upload and attach an electronic file to the request. Files up to 8 MB in size can be attached to requests during any stage where the request can be modified. Users can view and download attachments for any request to which they have access via their user roles and workflow node access group membership.

Request attachments can be deleted from a request by the user who added the attachment or by a user with the Data Manager role.

To add an attachment to a request:

Open a request from the Worklist.
On the Attachments tab, click , browse to and select the file to attach. Optionally, enter a comment, and then click OK.

To download a request attachment:

Open a request from the Worklist.
On the Attachments tab, click , select to open the file or save the file, and then click OK.

To delete a request attachment:

Open a request from the Worklist.
On the Attachments tab, click , and confirm the deletion.

Request Participants

Users who participated in a request can be viewed on the Participants tab. A selected user can be contacted if more information about their participation is required. You can view users who have participated in a request, the stage they participated in, the workflow action taken, and the time and date the action was taken.

To email request a request participant:

Open a request from the Worklist.
On the Participants tab, click next to the participant whom you want to contact.
Create email content, and then click Send.

Request Activity

All activities taking place for a request are recorded in the request activity. These activities include user activities such as submitting, approving, and enriching requests and system initiated activities such as assigning and committing requests. User comments are also recorded as request activities. Each activity includes a timestamp and name of the user if applicable. Activities are displayed with the most recent activity at the top of the list.

To view user and system activity for a request:

Open a request from the Worklist.
Click the Activity tab.

Workflow Tags

Workflow tags allow governance users to enable special handling of the request by a governance workflow. The following workflow tags can be added to a request that can be edited:

Due Date––Identifies a user-defined date for which changes in a request should be committed. The Due Date for a request establishes the date at which point the request gets marked as overdue if not yet committed. A separate worklist view is available for Overdue requests.
Urgent––Marks the request as high priority or time sensitive. A separate worklist view is available for Urgent requests.

To add a workflow tag:

Open a request that can be edited.
On the right side of the request next to Workflow Tags, click Add.
Select the workflow tags to add:
- Due Date
  
  Note:
  
  Make sure to select a date from the calendar.
- Urgent
Click OK.

To remove a workflow tag:

Open a request that has workflow tags assigned.
On the right side of the request, under Workflow Tags, click next to the workflow tags to remove from the request.

Workflow Path

The workflow path for a request identifies the stages of workflow to be completed, the active stage for the request, the completion status of previous stages, and the approval count for the active stage. The workflow path enables all participating users to understand how long a request may take, how many approvals may be involved, and where a request is positioned in the overall approval process. The workflow path is automatically updated as users perform actions such as submit, approve, enrich, push back, or reject a request.

The workflow path for a request is determined by:

The workflow model specified for the request
The request items in the request
The hierarchy nodes associated with the request items
The workflow user groups and their access levels to the hierarchy nodes
The workflow stages configured for the workflow model
The current stage for a request
The status of each stage