POST dms.request.objects.upsert.database-before (Webhook)

This webhook can be triggered by 

• an object import,
• an update of the content,
• an update or the metadata,
• or a tag update.

The webhook receives the completed objects just before they are indexed. This means that the objects are already enriched with system properties and default values (wherever necessary), normalized and validated.

In version 2021 Autumn, if there are invalid objects, the entry point of this webhook type is not reached. A validation exception is thrown before.

As of version 2021 Winter, the following behavior is implemented:

• Each object is still validated before the entry point of the webhook, but a validation exception is thrown after the webhook entry point. Thus, webhooks of this type can be triggered even in case of an invalid object.
• Those objects contain the corresponding validation errors in their options (see example below). Hence, it is possible to, e.g., add required properties to the original request body subsequently via a webhook.
• The object validation is performed again after the webhook. Only if there still are validation errors, a validation exception is thrown.
• If multiple webhooks of this type are configured, a validation is performed between every triggered webhook and its succeding webhook. Especially if objects have validation errors that were corrected by one webhook, the succeeding webhook gets the valid objects without validation errors in their options. If there are still invalid objects after the last webhook, then a validation exception is thrown.

{
	...
	"options": {
		"action": 300,
		"detail": "OBJECT_METADATA_CHANGED",
		"validationErrors": [
			{
				"message": "Illegal property. An object of type 'appEmail:email' cannot have a property named 'decSingle'.",
				"serviceErrorCode": 2607
			},
			{
				"message": "A required property is missing. property='appEmail:from'",
				"serviceErrorCode": 2300
			}
		]
		...
	}
}

The predicate is applied to every single object in the list. The webhook is triggered for the whole object list as soon as one object satisfies the predicate.

The objects returned by the webhook are normalized and validated again before the interrupted processing chain will be continued. Hence, by means of this webhook, it is not possible to introduce invalid objects into the system. Furthermore, the object list in the original request body cannot be completely overwritten. The following rules apply:

• It is not allowed to change the number of objects in the object list. An error will be thrown.
• It is not allowed to modify the value of the system:objectId property. An error will be thrown.
• System properties that are set by the system as well as content stream properties cannot be changed. An error will be thrown.
• The expiration date cannot be removed or replaced by an earlier one.
• If the value for system:parentId is changed, the new parent must be visible for the user who sent the original request.
• Data in the options section are read-only for the webhook. Changes will be ignored and the original values will be used. An error will not be thrown.
• If tags are added or updated, the properties creationDate and traceId of these tags are set or updated after the webhook.

• In general any changes of the object applied by the webhook must match the action specified in the options section. Otherwise, the original request will result in an error. Consider the restrictions for these specific action codes in particular:

  Value for 'action'	Restriction
  301	A webhook cannot change custom properties, retention properties or the system:secondaryObjectTypeIds property. However, as an exception, it is possible to add, update, or remove tags. Non-resistant tags are already removed from the object at this stage. A webhook can add resistant and non-resistant tags. All of them will be assigned to the final object. Further removals of non-resistant tags are not applied after the webhook.
  110/210/310	Only changes to the system:tags property matching the individual action are allowed.

Considering the action code, the webhook might be allowed to change tags. In the audit trail, the tagging-related entry will be the same if the tag modification was specified in the original request or by means of the webhook, e.g.: