In Sharepoint the majority of date is stored in so called lists. It is possible to listen to events on a specific list by using a custom C# class. The events you can listen on are: Adding, Added, Updating, Updated, Deleting and Deleted. After you receive such a event you can use the data and do all sorts of things with it. It is possible to create a so called event receiver by extending SPItemReceiver and overriding the events you want to handle. One of the possible events you can listen to is the ItemUpdated event. But from my experience with Microsoft Dynamics CRM 3.0 I know there are some important things to keep in mind before using the ItemUpdated event. In a Dynamics CRM enviroment you must 'never' update the item from which you receive the Updated event. I say 'never', but there are some situation in which it is allowed. But for all situation be carefull, because updating the item for which the Updated event was caused will cause a new Updated event. This will result in a 'never' ending Recursion. Yesterday I was thinking about this in the Context of Sharepoint Server, and together with Alex Thissen we tried out to be sure. We found out that the expected never ending recursion ended after 10 times. I'm not sure about the implementation for this, but I'm sure Microsoft did some tricks to make sure 'never' ending recursion do no occur. So, now I know this: Can I stop worrying about 'never' ending recursions? I don't think so, because the following situation isn't exactly what you would expect. For example: We listen to an Updated event for a buglist, and as a result of this event we send one e-mail out, and update the status field of the bug. What I would expect: An updated status field on the changed bug. And one e-mail send out. What I would get: An updated status field on the changed bug. And ten e-mails send out.