Workflows are not the way to go about it. You should be creating an item event receiver. The reason I say this is because it sounds like you have a need for some code to just run after you add an item. Since you don't need to maintain state then workflows are not the proper solution to this problem. Here's what you do: create a new class in Visual Studio and have it inherit from SPItemEventReceiver
. Override the ItemAdded()
method and put your logic in there. Ex:
public class MyItemEventReceiver : SPItemEventReceiver
{
public override void ItemAdded(SPItemEventProperties properties)
{
base.ItemAdded(properties);
// do your stuff
}
}
This code will be called after an item is added. If you need to have code run before the item is added then you'll be overriding the ItemAdding()
method. The way my company deploys event receivers is a bit different but this is the 'by the book' method using Elements.xml:
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Receivers ListTemplateId="101">
<Receiver>
<Name>My Event Receiver</Name>
<Type>ItemAdding</Type>
<SequenceNumber>1000</SequenceNumber>
<Assembly>AssemblyName, Version=1.0.0.0, culture=neutral, PublicKeyToken=[token]</Assembly>
<Class>Namespace.Class</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
</Receivers>
</Elements>
You mentioned having a screen to edit options of the code. It sounds like you're verging on another can of worms so I can't speak directly to that. However, if you want to pass in various options that differ from deployment to deployment then just throw those into the <Data>
tags above. Then you can access your options from the properties.ReceiverData
property within your code. Also, please note that the <Filter>
tags do nothing - they were not implemented by the WSS 3 team. Hope this helps.