That isn't how triggers work. Triggers are called when one or more rows are modified on a table. Within the trigger you get access to all the impacted rows, not the original query that was run. So any where clause on the original query isn't relevant here because the trigger just sees the rows impacted by that delete. What you have to do is take the impacted rows and find the corresponding rows in the original table and update them accordingly. Imagine, for example that your Products
table has a ProductId
column that uniquely identifies the row. Then you'd need to join the set of "deleted" rows with the original table to find which one's to update. Perhaps something like this.
UPDATE Products
SET Discontinued = 1
FROM Products JOIN deleted on Products.ProductId = deleted.ProductId
If my SQL is correct then this query takes all the rows to be deleted from the deleted
pseudo table, joins them back to the existing Products table and sets the corresponding rows to discontinued. But you should test this.
Note that triggers can be raised on a single or multiple rows so you should never assume a trigger is being run because of a single row change. Always build the trigger to run against all rows that were modified.