Tell me more ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.
up vote 1 down vote favorite

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.

share|improve this question
Didn't you choose what type of event the workflow should be triggered on during the workflow creation? – Daniel Ziga Feb 29 '12 at 2:17
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

4 Answers

up vote 2 down vote accepted

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.

share|improve this answer
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
up vote 3 down vote

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)
    {
        base.ItemAdded(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 = @"
                <d:Assignee>
                    <pc:Person>
                        <pc:DisplayName>Custom Group</pc:DisplayName>
                        <pc:AccountId>Custom Group</pc:AccountId>
                        <pc:AccountType>SharePointGroup</pc:AccountType>
                    </pc:Person>
                </d:Assignee>";

        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(
            properties.ListItem,
            approvalWorkflowAssociation,
            eventData);
    }

    /// <summary>
    /// An item is being updated
    /// </summary>
    public override void ItemUpdated(SPItemEventProperties properties)
    {
        // As above :)
    }
}
share|improve this answer
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
If you don't neeed to change any of the workflow's behaviour, then you only need this 1 line: properties.Web.Site.WorkflowManager.StartWorkflow(properties.ListItem, approvalWorkflowAssociation, approvalWorkflowAssociation.AssociationData); – Nick Larter Feb 29 '12 at 8:26
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
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
show 1 more comment
up vote 1 down vote

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.

share|improve this answer
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
This is what I've ended up doing. However you end up with further issues, if the column isn't hidden then it appears on the forms, if it is hidden you can't change it's value in the workflow... It doesn't feel particularly elegant, but maybe this is a forlorn hope in SharePoint. – AdamH Feb 29 '12 at 4:26
show 2 more comments
up vote 0 down vote

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?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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