Updating multiple records
The Mass Update group actions menu option allows you to specify values that will be applied to all selected records. Platform creates a default Mass Update page that displays when a user selects this option. The default page exposes no fields. You can edit the page to add and remove fields by selecting Design this Page from the Page Options menu. If you add a field to an existing object, you have the option of including it on the Mass Update page (among others). If a Mass Update page has multiple fields, only those in which a user enters values will be updated.
If you add a lookup field for a related object in a Mass Update page, the updates follow the rules defined for the relationship. For example, in a relationship where one device can only be related to one room, if a user selects that device, it will only be updated in the first record.
To support updates of different sets of fields on the same object, you can create multiple pages by cloning the the Mass Update page in the object definition. When multiple Mass Update pages exist for an object, Platform adds them as an option to the group actions menu. The following screen shows an example of a menu option for a custom Mass Update Furnishings page that an administrator added to this object definition.
With Platform 5.12, mass update of large set of records comes with the capability to default to asynchronous processing as against the earlier behavior of always updating records in synchronous mode. This functionality can be managed with the MaxRecordsForSyncMassUpdate shared property.
Asynchronous processing
Assume the user selects records more than the permissible limit as specified in the shared property which runs in a synchronous mode. On submitting a mass update request, a large job is queued, which is picked up based on the availability.
On job completion, the user is notified by an email which includes the information on the count of records or fields skipped from being updated due to insufficient edit permissions (if any) or any exceptions occurring while executing any trigger. The trigger details are logged in the event.log file. The system administrator has access to these logs.
Mass updates in an asynchronous processing now provides a better cache life-cycle management. This functionality avoids any accidental over-utilization of resources while processing very large data set of records.
Usage of HTTP request based APIs in trigger/validation scripts like
rbv_api.getHTTPCookieandrbv_api.getHTTPParameter()etc are no longer supported.Each selected record in mass update flow, is updated in its own context. Context sharing using trigger to trigger APIs are no longer supported.
For an optimal performance, all the permission checks are performed at the time of actual job execution and not during the job submission.
Validation triggers are no longer processed at the time of mass update job submission. They are still executed during the actual mass update run. Any record skipped from the mass update processing is intimated on job completion e-mail after the mass update has finished processing.
Mass Change to any workflow status (with/without intermediate status change page) from the More Actions is treated as a Mass Update operation and consequently follows the restrictions set on the MaxRecordsForSyncActions for any synchronous large job operations.
In case of a mass update job, if a record update fails due to any error (even apart from validation exception), the job does not stop and all the records where any error exist are skipped for mass update.
