cross channeel posting Has anyone encountered issues with the built-in Mass Price Update not triggering User Event scripts or logging changes? We're using the built-in Mass Update for pricing (Lists > Mass Update > Pricing) and running into two problems: 1. After the mass price update runs, the afterSubmit User Event script deployed on the Inventory Item record is not being triggered. The script works fine when editing records through the UI, but does not fire during the built-in mass update. 2. The price changes made by the mass update are not showing up in the System Information / System Notes on the record — there's no audit trail of the change. Is this expected behavior for built-in mass updates? If so, what's the recommended workaround — Workflows, Custom Mass Update scripts, or something else?

They behave a bit differently - "Be aware that a record change that results from a mass update can trigger a related user event script as the same change not made through a mass update would. However, in the case of the mass update, the full record is not passed to the user event script; instead, only the field(s) changed by the mass update are passed."

in our testig the user event scriptt was not triggered

For example, you just have a log statement at the beginning and it doesn't log anything?

correct only if i went into ui ( or another script etc )

Sounds like maybe Mass Update uses xedit (inline edit / submitFields) then, rather than a full record load-edit-save approach. If that's the case then maybe your UE script deployment for that record type: • Doesn't exist for that record type • Isn't Deployed • Is set to only handle one user event type (like Create) • or Has its Execution Contexts set so it only runs on User Interface or something like that, but not on Mass Update. • or has its suitescript code made so that it conditionally doesn't perform the actions when running from Mass Update context. • or is running as a Role that can't access what it needs to to get the job done. If my hypothesis is correct and it really is using xedit (AKA inline-edit or submitFields), and the code relies on reading values from newRecord that have NOT been changed before submitting, then that code will fail to work correctly, because in an inline edit / xedit event, then fields that did not change are not included in the newRecord object. So that can trip you up too.