Thank you all for your interesting suggestions. Maybe the CONTEXT_INFO solution is the best in my case: separate logic for AFTER DELETE is good, but in my case the logic is just the same for all conditions (populating a "bridge" table with changes); app name is interesting, but the same app has a "normal" part which needs triggers and a "maintenance" part with bulk deletes which should disable only the AFTER DELETE (I could change the app name).