In our implementation of Matrix (5.1.6.0), we’ve opted not to send workflow emails on ‘Approved’ status, but instead we have a trigger that sends an email to the relevant Approver and the central web team when an asset has a Status Change to Live. The only issue is when someone Cancels Safe Edit (therefore returning it to Live status) it is also triggers the same email.
Has anyone got a way I can exclude the ‘Safeedit Cancel’ event from the trigger, so that an 'Asset Made Live' email isn't sent to them?
This is what my trigger looks currently looks like.
Event = Status Changed
Conditions = Asset has the current status of Live
Tree Location = (I have a few assets listed here – tops of branches)
Asset is of type = Page, News Item, File, Abstract Calendar Event
In our implementation of Matrix (5.1.6.0), we’ve opted not to send workflow emails on ‘Approved’ status, but instead we have a trigger that sends an email to the relevant Approver and the central web team when an asset has a Status Change to Live. The only issue is when someone Cancels Safe Edit (therefore returning it to Live status) it is also triggers the same email.
Has anyone got a way I can exclude the ‘Safeedit Cancel’ event from the trigger, so that an 'Asset Made Live' email isn't sent to them?
This is what my trigger looks currently looks like.
Event = Status Changed
Conditions = Asset has the current status of Live
Tree Location = (I have a few assets listed here – tops of branches)
Asset is of type = Page, News Item, File, Abstract Calendar Event
I tried the trigger you suggested J.P, but it unfortunately didn't work.
I then tried the trigger with the inverse condition that you suggested Tim, but it isn't working either.
I'm wondering if there's a conflict from the 'Before Status Changed' with 2 other existing triggers that make 'Approved to Go Live' and 'Safe Edit Approved' assets go live via a Future Status cron job? Have you had any experience with conflicting triggers?
Shouldn't be a conflict here. We've got an auto-live setup similar to what you're describing with future statuses. I'm wondering if it's other conditions having an issue. You may need to do some debugging. Cut it back to just barebones and add one condition at a time, change the action to send you an email. Make sure it's sending you emails with the most basic conditions, than add them back in and test after each one, see where it actually stops working.
Tim's debugging suggestion is the way to do it - however use the system log to determine if your trigger is firing (assuming trigger.* is in the logging whitelists) - it could be firing unnoticed if your action is misconfigured.