Mass updates on requests

You can perform the same action on multiple requests of the same request type simultaneously, instead of updating each request individually.

Tip: The mass update feature is enabled by default. To disable it, set the DISABLE_QUICK_EDIT_MASS_UPDATE server configuration parameter to true. For more information, see the Demand Management Configuration Guide.

Advantages of performing mass updates

Performing mass updates is advantageous in scenarios as the following:

You want to assign the same developer to 20 newly created defect requests. This involves updating the Assigned To field on all 20 requests, and updating the Status field New to Assigned.
You are assigned 15 requests, because you are going on an extended vacation, you need to reassign all these requests to another engineer.
To make sure the same specific stakeholders can receive the notifications generated from the escalations from a designated customer account, you need to add the same set of specific stakeholders to these escalations.

Considerations for performing mass updates

Consider the following before you perform mass updates on multiple requests:

Caution: If your PPM instance supports multiple languages, remember that request types can only be modified in the language in which they were initially defined. If you cannot edit a request type because it was defined in a language different from your current session language, log out of PPM and then log on again, this time selecting the request type's definition language as your session language. For more information, see the Multilingual User Interface Guide.

Consideration	Details
Limited to requests of the same request type	You can only perform mass updates on requests that are of the same type. So, when you search requests, select only one request type if you plan to perform mass updates.
Not applicable to advanced UI rules	Advanced UI rules that have been set up for requests do not work during mass updates. For example, any UI rules defined to dynamically show or hide a field, change the field styling, or make a field required, are not applied while a user performs a mass update. However, upon saving the requests, any fields that would have been dynamically required based on other edits made by the user are enforced.
Applicable to standard request fields only	You can update standard request fields (such as text fields, date fields, and lists), workflow actions, and you can add notes to requests. You cannot perform mass updates on complex components such as attachments, table components, and entity-chooser components (such as staffing profiles).
Requests should be at the same workflow step and limited to one step at a time	If all of the requests you select to update are active at the same workflow step, you can take action on that step for all of the requests. However, you can update only one active workflow step at a time.
Impacts on automated processes	Evaluate the potential impact of mass updates on automated processes. Any updates you perform may trigger subsequent updates to additional fields that are dependent on the changes made.

Error handling in mass updates

When you click Save or Done, the system attempts to save all of the requests you have updated. If problems are encountered, it displays a list of the requests that could not be saved and the reasons the saves failed.

Errors can occur if:

A request was updated by a different user in another session before you saved your changes.
A UI rule to make an empty field required was triggered on save. For details, see Considerations for performing mass updates.

Perform mass updates

To perform mass updates on multiple requests simultaneously:

Search for requests of the same request type.
On the Request Search Results page, select the check boxes for the requests to update.
Click Edit, and then select Mass Update.

The Modify Requests page opens and lists the selected requests.
Do one of the following:
- If the Available Actions section is available, you can click an action button to take action on the same workflow step for all the selected requests.
- To enter the same description for all the requests, type it into the field below the Description column.
  
  To empty the Description field for all the requests, below the Description column, select the Apply Blank checkbox.
- To assign the same resource to all the requests, under the Assigned To column, select resource to assign.
  
  To empty the Assigned To field for all the requests, below the Assigned To column, select the Apply Blank checkbox.
- To assign the same priority to all the requests, from the Priority list below the Priority column, select the priority value.
  
  To empty the Priority field for all the requests, below the Priority column, select the Apply Blank checkbox.
Note: You can only use mass update on the columns for which fields are provided.
Click Done.

The Request Mass Update Confirmation dialog box opens and lists the changes to make.
Click Continue to confirm.

If any of the changes you specified could not be implemented, a message to that effect is displayed in the upper-left corner of the page next to the warning icon , along with a link to view a separate window that lists of all requests that could not be saved, and a description of the reasons.

Note: You can also use mass update functionality from the Request Browser. For instructions on how to use the Request Browser to search requests, see Search for requests by generic request field values.

Field level security check

PPM performs security check on mass updates by adding pre-checks to the following scenarios:

Scenario	Details
When clicking Mass Update on Request Search Results page	When you click Mass Update to perform mass updates on selected multiple requests, a security check is performed to verify the selected requests for potential issues that might cause the mass update operation fail. The security check includes the following pre-checks: Status dependencies check. Checks field status dependencies for non-editable fields. Field level security validation. Validates field level security of the selected requests to see if the user has appropriate privileges. Display-only check. Checks for display-only fields. With these pre-checks performed, the Request Batch Update page displays the requests for updates accordingly: If one column is not editable for ALL the selected requests, then this column is displayed as read-only and grayed out. If one column is editable for at least one request among the requests that users selected to update, then this column is displayed as editable.
When clicking Save or Done on Request Batch Update page	When you click Save or Done on the Request Batch Update page, some more applicable pre-checks are performed, such as checking the status of requests whether they are still valid for the mass update. If any potential errors exist, for example, The pre-check finds that the Editable option for a request field is set to No for the current status, then update to this field would not be applied. A request contains fields that users do not have authorization to edit, then the request could not be updated. Then, warning messages are displayed on the Request Batch Update Confirmation page, listing requests that could not be updated, with a descriptions of the reasons. This pro-active warning message would enable users to decide whether they want to continue or not.
Workflow transition check	When you click any workflow actions on Request Batch Update page, some pre-validations are performed, including security check, check request status, and check whether an action is still available for the selected requests. If any potential errors exist, warning messages are displayed on the Request Batch Update Confirmation page for users, listing requests that could not be updated, and a description of the reasons.

Scenario

Details

When clicking Mass Update on Request Search Results page

When you click Mass Update to perform mass updates on selected multiple requests, a security check is performed to verify the selected requests for potential issues that might cause the mass update operation fail. The security check includes the following pre-checks:

Status dependencies check. Checks field status dependencies for non-editable fields.
Field level security validation. Validates field level security of the selected requests to see if the user has appropriate privileges.
Display-only check. Checks for display-only fields.

With these pre-checks performed, the Request Batch Update page displays the requests for updates accordingly:

If one column is not editable for ALL the selected requests, then this column is displayed as read-only and grayed out.
If one column is editable for at least one request among the requests that users selected to update, then this column is displayed as editable.

When clicking Save or Done on Request Batch Update page

When you click Save or Done on the Request Batch Update page, some more applicable pre-checks are performed, such as checking the status of requests whether they are still valid for the mass update.

If any potential errors exist, for example,

The pre-check finds that the Editable option for a request field is set to No for the current status, then update to this field would not be applied.
A request contains fields that users do not have authorization to edit, then the request could not be updated.

Then, warning messages are displayed on the Request Batch Update Confirmation page, listing requests that could not be updated, with a descriptions of the reasons. This pro-active warning message would enable users to decide whether they want to continue or not.

Workflow transition check

When you click any workflow actions on Request Batch Update page, some pre-validations are performed, including security check, check request status, and check whether an action is still available for the selected requests. If any potential errors exist, warning messages are displayed on the Request Batch Update Confirmation page for users, listing requests that could not be updated, and a description of the reasons.