views:

671

answers:

3

I want to build a custom content type that will be the basis of a list item that will have multiple states. The various states will determine which list will instantiate this item. It will move between the states, and therefore the lists, based on user actions.

I have a few choices to implement this:

  1. Create workflows on each list that handle the specific functions related to that list. Move an item to another list when necessary (copy item to new list, delete orig item), and let that workflow kick off.
  2. Create a workflow on the custom content type we will be using, and let that move the item between the various lists. Not sure if a workflow on a content type can move from list to list, let alone across site collections.
  3. Use the event receivers on the custom content type to manage state. User acts on an item, changing its state, so the event receiver creates a copy of itself on the other list and then deletes itself on the current list. I know this works across site collections.

Which way is best, and why? Anything that absolutely will not work? Any method I've overlooked?

+2  A: 

In my opinion, use event receivers, as these follow the item rather than the list. You still need to enable the content type for the receiving list, but this approach is a lot easier than updating and deleting workflows in lists based on the presence or absences of certain content types.

However, why not combine the approaches? Have the content type event receiver deal with the content type specific activities and let the lists handle any list specific activities. Event receivers are cheap and flexible.

.b

Bjørn Furuknap
+2  A: 

Generally speaking: In SharePoint workflows and event-receivers are related (if you look at the events on a list with an attached workflow you will find a event-receiver starting the workflow..)

The advantage of workflows is the possibility for the user to check the log (given that you use the Log-Activity)

The advantage of event-receivers are the greater number of events; they are more flexible than workflows.

From what you describe i would probably choose workflows, so the users can check if their item was processed correct.

What prevents an event receiver from logging events?
Bjørn Furuknap
Nothing prevents an event receiver from logging events - but the user will not be able to see this logging
Unless you "log" your events to a list that is viewable to the user, right?
Nathan DeWitt
Yes, unless you "log" your events to a list that is viewable to the user- i.e. the list "Workflow History", where the workflows put their log.
but Bjørn was talking about logging from events specifically, which can log either to a windows log file, or a sharepoint list, or a database, or wherever you want.
Nathan DeWitt
+1  A: 

I use the workflow associated with each list approach because I need the workflow history as an audit trail for which user does what. I rather like the idea of a workflow on the content type however and in retrospect this would have been the cleaner solution to what I've done.

Dan Revell