Noting that your Trigger Condition is "Committed Delete", are you looking at the lines in the Tracer following the 'Commit' event? Have you experimented with just the "Delete" event.
Check also that you don't have any When conditions governing whether the Trigger activity should run. You should still see these in the Tracer and evaluating to 'false' if that was the case.
Lastly, check the logs to see if there's some runtime issue where it attempts to run but doesn't, but fails silently in the core interaction.
The help docs do advise the Declare Triggers can't be created on Code-* and Embed-* subclasses (this help link is for 8.4, but I know this dates back to 7.x). I think that constraint is applied on the New Rule form so if System-* was fell under the same constraint you should have been blocked from creating the Declare Trigger.
Failing that, raise a Support Request. Nothing I've just read suggests this is not supported.
Posted: 1 year ago
Updated: 1 year ago
Posted: 21 Feb 2020 15:16 EST Updated: 21 Feb 2020 15:17 EST
After more analysis I got to know that the issue is, Pega saves the System-Locks instance via Java. So as Pega does not use obj-methods to save/create an instance of System-Locks, declare trigger will not be triggered.
Posted: 1 year ago
Posted: 23 Feb 2020 15:50 EST
Braam Smith (BraamCLSA)
Partner Success Tech Lead - APAC
Is another way to approach this to have the Declare Trigger run on the Committed Save of the item that you have locked? In other words is the actual event of interest 'the save of a lockable item' as distinct from 'the release of the lock' ?
Inheritance applies for Declare Triggers, so if there are a range of work classes that this behaviour should be triggered for (MyCo-MyApp-Work-A, MyCo-MyApp-Work-B, MyCo-MyApp-Work-C), you can implement the trigger once with the Applies To class set to their most common superclass (MyCo-MyApp-Work) and the trigger will fire on the Committed Save of instances of any of its subclasses.