Is there any way of identifying if my SPD (2010) workflow was initiated by item creation or by item modification? I don't want to split the workflow into two as 99% of the workflows would be identical.

  • Didn't you choose what type of event the workflow should be triggered on during the workflow creation? – user2536 Feb 29 '12 at 2:17
  • 1
    Yes it's associated with both creation and changed. I need to know which of these triggered the workflow as I have 1 action that should be different if it's on creation. – AdamH Feb 29 '12 at 3:30
  • If you use your own history list, and write at least one entry to it each time your workflow runs, you can then do a lookup to that list in SPD as part of an if statement. Return the item ID of an item in the history list whose Parent Item ID matches the current item ID. A value greater than 0 indicates that your workflow has ran on this item before (modified) whereas 0 indicates this is the first time it has run (created). – Lou Nov 29 '12 at 20:17

Compare the values of your Current Item's Created column and Modified column in your workflow. If the two datetime values are equal, your Current Item is newly created. Else, your Current Item's been changed.

  • I'd wondered if something like this would work, but didn't test it. Do you know if the times are exactly equal or just very close? – AdamH Mar 1 '12 at 1:07
  • Adamh, they are exactly equal. Each time you create a new item, SharePoint gives you the same created and modified time. I'm using it in many scenarios. – Jony Mar 1 '12 at 1:39
  • Excellent, I wish I'd tested this now as I'm doing the hidden field with default value thing and it's a bit fiddly. – AdamH Mar 1 '12 at 3:31

You can create an event receiver on your list and then programatically kickstart your workflows in each of the ItemAdded and ItemUpdated events (as apposed to having them start automatically).

This allows you to:

  • Determine exactly what event had triggered the workflow, and
  • Modify your association data for each scenario, if required (NB: the association data is an XML string containing any custom data that you need to pass to your workflow)

An example...

Let's say you have a basic approval workflow, and the only difference about the approval process for new vs updated list items is that the tasks must be sent to a different user / SharePoint group.

Obviously you don't want to create 2x identical workflows here just so that you can assign them to a different user / SharePoint group! So instead you create an item event receiver on your list which traps the ItemAdded and ItemUpdated events. Inside each of these methods you simply load your one approval workflow and then programmatically assign the appropriate approver to it.

I have provided some code stubs below:

/// <summary>
/// List Item Events
/// </summary>
public class MyListItemEventReceiver : SPItemEventReceiver
    /// <summary>
    /// An item was added.
    /// </summary>
    public override void ItemAdded(SPItemEventProperties properties)

        // Get your approval workflow that is associated with this list. 
        SPWorkflowAssociation approvalWorkflowAssociation = properties.List.WorkflowAssociations.GetAssociationByName("Approval Workflow", CultureInfo.InvariantCulture);

        // Update the association data (this example is purely trivial).
        string assigneeElement = @"
                        <pc:DisplayName>Custom Group</pc:DisplayName>
                        <pc:AccountId>Custom Group</pc:AccountId>

        string eventData = approvalWorkflowAssociation.AssociationData.Replace("<d:Assignee />", assigneeElement);

        // Manually start the workflow, passing it the updated association data.
        SPWorkflow approvalWorkflow = properties.Web.Site.WorkflowManager.StartWorkflow(

    /// <summary>
    /// An item is being updated
    /// </summary>
    public override void ItemUpdated(SPItemEventProperties properties)
        // As above :)
  • So with this plan the code is just being used to kick off a SPD worfklow? – AdamH Feb 29 '12 at 5:11
  • Correct. Instead of having your workflows start automatically and then trying and work out where / why they were initiated, just start them manually during the appropriate event. All the stuff I put in there about changing the workflow's association data is entirely optional -- but I thought I'd just show you how you could change one of the workflows behaviour if need be (since you said they were 99% similar). – Nick Larter Feb 29 '12 at 8:19
  • 1
    I think this is a great way of doing it, but I'm accepting the dates comparison method as the answer as I don't have to leave SPD to do it. I think if I'd been able to use Visual Studio on this project I'd have probably done the workflows in a completely different manner that would hopefully have bypassed this issue. – AdamH Mar 1 '12 at 3:35
  • 1
    Comparing dates is hacky. What happens if an event receiver somewhere changes the item before you date comparison runs? Then you could get a very different result to what what you were expecting. Using the list item's event handlers is full proof as it gets executed beofre anything else in sharePoint (workflows, timer jobs etc) have the opportunity to access your list items. In regards to using Visual Studio, that's another whole topic for debate. I'm of the school of thought that everything should be done there so it can be wrapped up into a deployable and reusable solution, feature etc. – Nick Larter Mar 1 '12 at 3:56
  • 1
    Nick, I agree that Visual Studio is the way to go; features, upgrades, repeatable deployment, the list is endless or at least long. However in this project it wasn't an option, I hope to change this for future projects as I can't say I enjoyed the experience of creating workflows in SPD. – AdamH Mar 1 '12 at 4:00

When you associate a workflow to a list, you specify how the workflow is triggered: on creation, on change or manually. You can select one or many. Check the workflow settings (List Settings > Workflow Settings) and see how the workflow is associated.

  • I know how it's associated, I need to see which of the actions triggered the script at runtime. – AdamH Feb 29 '12 at 3:30
  • OOoooo... do you want to determine within the SPD workflow whether it was triggered on create or change? – David Lozzi Feb 29 '12 at 3:49
  • Yes that's exactly what I need. – AdamH Feb 29 '12 at 3:52
  • Okay then, what I've done is use a field to indicate the status. Use a field with a default value, on the first time through, update it. Then you'll know how it was triggered. – David Lozzi Feb 29 '12 at 3:57
  • 1
    The field should still be available from SPD workflows if you check Hidden (Will not appear in forms for the field under the content type in the list. – Anders Aune Feb 29 '12 at 7:25

AdamH, your flag was to determine if a event was hit. Why do you need to reset it? Couldn't you just add another hidden field? You would just need Create and Changed, right?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.