Hi,
It might very well be a good starting point to learn how to code plugins, however there's a bit light on information to give you any good pointers.
In general you want to register plugins in pre-state, this is true if you are modifying data on the calling entity. The reason why you want those plugins in the pre-state is that you manipulate data before the database operation and thus saves one database
operation (which is A LOT of database calls btw).
For plugins that manipulate other entities you probably want to use "complete" data and those would probably be registered in the post state and use a post state image to retrieve all the fields you want to use on the record. When you call a plugin
the only fields you get on the incoming message are the changed fields, you can of course get all fields using a pre state image too, but that would not give you the data present after db-operation where you could have other plugins doing business logic for
you.
You could also argue if it's better with a workflow or not depending on when you need the data considering that workflows are asynchronous processes and will be executed when there's time to do so while a plugin can be set to run synchronous or asynchronous
depending n what you want to do.
That you get an answer like mine and Rob's is that it might be a better architectural solution to have a workflow sometimes plus it cuts down on development and test time.
Hope it helps.
Rickard Norström Developer CRM-Konsulterna
http://www.crmkonsulterna.se
Swedish Dynamics CRM Forum: http://www.crmforum.se
My Blog: http://rickardnorstrom.blogspot.se
