Kick off workflow from SPServices List Update?

Oct 5, 2010 at 8:27 PM

First, allow me to tip my hat, bow profusely, and thank you Marc for being such an outstanding (and monstrously patient!) reference to those of us in the SharePoint world.  I'm working in an environment in which any and all code which can be done without delving into ASP.NET is welcomed - the path from development to production is so much shorter!  But I digress...

My question may not be specific to SPServices, but here it is:  I am building an application and using several buttons to make instant list item updates on a dashboard, similar to one of the examples you have on the site.  Right now, however, none of the associated workflows (specifically, a customized email) are being kicked off when items are updated.  The item is being updated properly; I can see it in one of our test views, however no emails are sent, and the workflow is clearly not being activated because it has no workflow history, and no status.  the workflow does kick off when I update the item manually.

Is this expected behavior, and do I need to reading up on the workflow kickoff feature in spservices, or could there be something wrong with my code?

thanks so much!

-Rob

Oct 29, 2010 at 1:03 AM

Same here, I used UpdateListItems to modify a field in a list, but the workflow didnt initiated. The modification saved correctly, the version of the item changed.

When I used the default editform the workflow worked.

Is there any difference between the standard update and the UpdateListItems method ?

Thanks,

johny

Nov 3, 2010 at 5:17 PM

Well I've done some pretty thorough testing and debugging, and the result is this:

When using web services to Update a List Item, workflows will NOT be automatically kicked off as a result.  In other words, if I have a list with a status field, and I update that status field with a value that should "On Update," kick off a workflow - this does not happen.  There must be an event handler in the normal forms that activate workflows, and it is not present when you run them using web services.  I've modified my buttons to kick off status updates and then immediately run the workflows afterwards... although this brings some configuration challenges with it.

Coordinator
Nov 3, 2010 at 6:07 PM

Rob:

I'm sorry to not have gotten back to you or Johny on this sooner. I sort of suspected that what you arrived at was the answer. Remember: I didn't write the Web Services, I just wrap 'em! You'll have to take it up with the folks in Redmond. ;+)

M.

Nov 5, 2010 at 3:39 AM

No sweat, Marc - 

You're right; it's certainly nothing that the SPServices library is (or isn't!) doing that's caused this.  There seems to be an event handler missing in the original code.  No matter; where there's a will, there's a workaround!

On a side note, the call workflow function is operating flawlessly, and once I integrate your GetTemplateID function as well, I believe we'll have completely portable code!  What I've done is created a dashboard with buttons inside a dataview, and the buttons themselves will kick off individual  workflows.  I  just incorporated the field update into the workflow, rather than having the workflow run based on the field update, if that makes sense.

On a side note. I spent the afternoon modifying the GetLastItemID function to pull from a different field - yet another workaround I had to make use of  due to a pretty huge bug in the Infopath-to-SharePoint implementation - the "copy" function does not work properly for infopath forms; it ends up copying the .xsn template rather than the .xml data, which ends up being basically useless.

 

Our workaround was to create yet another workflow which copies a blank version of the xml template (stored elsewhere), then updates the file with all the values from the source file.  It's a pretty expensive workflow, but it does the trick!  GetLastDocId ends up pulling from a field called "document owner" and retrieves the filename of the copy destination document so that it can be opened in a new window, all from the same dashboard button.

 

Carry on - I think we've solved the original issue here - 

thanks again; I wouldn't be able to do any of this stuff without your EUSP posts and this library!

Coordinator
Nov 5, 2010 at 4:11 AM

Excellent, Rob. If you've got the time for it, I'd love to do a post for EUSP and my blog on what you are doing. If you could spare a couple of screenshots, I could write the text (or you're welcome to). If it's sensitive in some way, we could of course obfuscate however you'd like.

Thanks for the update!

M.

Nov 5, 2010 at 3:59 PM

Before you give up totally on workflows being kicked off from a webservice update, there is a small bug that you should be aware of. I am not sure the code you are using to update the item, but if this is a document library, you have to include the full path to the document in a CAML query to get this to work. I saw this on stack overflow here

Nov 7, 2010 at 11:25 PM

Ahh, what a bug... It was a document library, so I added the "FileRef" field also to the update, and voila It worked.

Btw, I tried to delete an item from the document library, and it is just working with the same logic, so you have to provide the "FileRef" in the query as well.

Thanks a lot for the hint,

Johny

Coordinator
Nov 10, 2010 at 2:03 AM

I'd love an example from what any of you have done on this for the SPServices docs, but also for something for EUSP if you have the time.

M.

Nov 10, 2010 at 9:14 AM

Marc,     I am currently not using this to kickoff a workflow. I am using this to perform a print function through Excel and javascript. I was planning on updating my blog with that info. If you want to use that, just let me know.

Dan

 

Nov 11, 2010 at 10:30 AM

Hi Marc, here is my example:

$().SPServices({
    operation: "UpdateListItems",
    async: false,
    ID: 1234,
    listName: "Test",
    valuepairs: [["Comment", Comment],["FileRef", FileRef]],    
    completefunc: function (xData, Status) {
    }
});

So if you have a workflow on doc library and update an item from webservices, you also have to provide the FileRef value. Otherwise you will update everything on that item, but the workflow never start.

Johny

 

Coordinator
Nov 12, 2010 at 2:00 AM

Thanks, Johny.  This is a good find! I'l probably try to do a blog post on this soon.

M.

Nov 15, 2010 at 3:33 PM

Hi all -

 

My apologies for not getting back on this; I've been away a few days.

 

For our purposes, I've built a custom dashboard that has a number of items rendered in a standard data view, and there are 3 or 4 buttons (depending on the view) that kick off a variety of workflows.  The actions are basic: Confirm, Cancel, Delete, Copy, etc.  One of these deals:

 

 

Start Date End Date Location Name Copy This Item Delete This Item Cancel This Item  
11-11-10 11-12-10 Paris, FR Oscar the Grouch <button>Copy</button> <button>Delete</button> <button>Cancel</button>
12-11-10 12-12-10 Washington, DC Big Bird <button>Copy</button> <button>Delete</button> <button>Cancel</button>
1-11-11 1-12-11 Selkirk, NY Cookie Monster <button>Copy</button> <button>Delete</button> <button>Cancel</button>

Hitting one of the buttons puts a jquery overlay over the screen, displays a "working" ajax loader .gif, kicks off a corresponding workflow which updates item status (or copies), sends a few emails and calculates some other items for other functions.  Upon a successful completion (returning the 'out' variable with no errors), the row is faded out and removed from the table row and the user moves on.  The Copy function additionally creates the new item, finds the new ID based on a version of the "GetLastItemID" function that I modified, and opens it in a modal window for the user.  

We have a number of other great functions and jquery implementations in this release - I'm very proud of it!  

I'll be happy to send you a screenshot, or help to write up a blog post - how shall I get started on that?  Obviously several items would need to be obfuscated but I think the general idea will still come across.