Working with products in triggers, validations and price types
Copy the link to the article

Order details are an array of data, therefore, working with them is conducted using special filters created in PipeLanguage. In this article, we will analyse how to work with filters in price types, triggers and validation and in the context of products.


In the condition of applying price types, the syntax for referring to products will differ from referring to them in a trigger or validation, since the price type is applied to a product item that is not a data array.

You can familiarise yourself with and choose the filter suitable for the situation you need in the "Language of expressions" article. Consider a trigger that will react to the transfer of an order to the "Completed" status, with a check that all products in the order have the "Sold" status and send an e-mail to the customer asking for feedback.

Let's specify the following code in the trigger code:

changeSet.hasChangedField("status") and changeSet.newValue("status").code == "complete" and order.availableOrderProducts | every(item =>item.status.code == "saled")

In this code, the "every" filter is used, which will let the trigger to be executed only if all the elements of the array satisfy the condition specified in brackets.

Let's consider a popular situation with a trigger that checks that a product from a specific list of products is added to the order, and sets a task for the responsible manager to add a gift to the order.

Let's create a trigger with the following code:

changeSet.hasChangedField("order_product") and changeSet.newValue("order_product") and order.availableOrderProducts | contains (item => in ["1","2","3"])


IDs of trade offers can be viewed in the ICML catalogue of products.

In this trigger was the "contains" filter was used, which will return a successful result if the conditions specified in the filter brackets are satisfied in the order.

PipeLanguage has the "reduce" filter that can aggregate the required elements in an array and return an aggregate result.

Consider a trigger that will sum up the value of the product dimensions from the additional product properties that were entered in the ICML catalogue, and write the result into the corresponding dimensions fields in the order as soon as new product or order details are added or deleted.


With the help of the "reduce" filter, the trigger will be able to perform a mathematical action only with additional properties without special processing, that is, those that are added via the "param" tag.

Let's add the following code to the trigger:

(changeSet.hasChangedField("order_product") and changeSet.getNewValue("order_product")) or (changeSet.hasChangedField("order_product") and changeSet.getOldValue("order_product")) 

In the action of the trigger, select the change in the "Height" field, in the expression we specify:

order.availableOrderProducts | reduce( (sum, x) =>sum + * x.quantity 

This code will work for all products in the order and will sum up the value of their additional properties with the symbolic code "height". Using a similar code, you can apply this case to other dimensions, such as "Width" and "Length" fields, by changing only the symbolic code of the additional property to the appropriate one.

Almost all online stores maintain stock balances from specialised warehouse systems, and exporting or uploading balances can occur upon the event that orders are transferred to a certain status. In order to exclude situations when a manager forgets to reserve a product in an order and transfers it to a shipment status, we will create a validation, which will be executed on the change of the order status, checking the array with the composition of products for the presence of a non-empty array with packs in it:

changeSet.hasChangedField("status") and changeSet.newValue("status").code == "send-to-assembling" and not order.availableOrderProducts | every (item =>item.packs | contains (pack =>pack))

To create a condition for applying a price type, you do not always have to use pipe filters, because the price type is applied to one product item and, accordingly, is not an array. Let's generate a code that will apply the type of price we need if a buyer buys 10 or more pieces of one item:

item != null and item.quantity >= 10
Thank you for your feedback.
Was this article helpful?
  • Рекомендации не помогли
  • Нет ответа на мой вопрос
  • Текст трудно понять
  • Не нравится описанный функционал
Previous article
How to set up a trigger chain
A Trigger chain is a sequence of communications that are aimed at automatically informing the customer about the progress of their order via timely updates.
Next article
Points to note when forming a validation
Validation is designed to create additional checks for changes in fields that the user makes in the system.