question

If I understand you correctly, you want to know how the "magic" tables `inserted` and `deleted` are created when a trigger is created. These tables are internal system tables that you do not create by hand - they basically give you read-only access to the previous state of a row when you have made a change. They offer up the same columns as the base table the trigger has been created on, just with the data as it was before deletion/update or for inserts, the exact data that has been inserted. You can then use this information to start a secondary process behind the scenes. One word of warning though - triggers can be a hidden source of great performance pain - if you have to do asynchronous data processing, use service broker or a hand rolled asynch process. A trigger can and will slow down an in-flight transaction, just about everything you can think of putting in a trigger can be done outside of one.