In that case, in addition to what Twan mentioned about people not being aware of the deleted and inserted snapshots, lots of people who do know about the snapshots are not aware that if a trigger fires for an action spanning multiple rows, then the snapshots contain multiple rows too.

So if the original question is on how to send the data from the snapshots to a procedure, then I'm afraid it can only be done the ugly way: in the trigger, open a cursor on deleted or inserted, then loop through the cursor calling the procedure with the parameters you're retrieving from the cursor.

Like Frank said, triggers are synchronous, so it would be irresponsible to implement such a trigger ...

Anyway, the only valid reason for doing this stuff in triggers is when data is manipulated directly on the table. If you can force the use of only stored procedures to manipulate the data, then you can certainly define the whole follow-up processing in the stored procedures, instead of in triggers.