11

I have seen elsewhere, that for whatever evil reason, SP2010 list workflows cannot be triggered by the delete of a list item. Glad the SP dev team didn't design soda machines or you'd never have a CHANGE slot or get your dollar back if it was too wrinkled.

Anyhow, I'm still in need of what really should be baked into the product, a means of firing off a workflow when a list item has been deleted. The workflow being fired will be counting the number of list items meeting a criteria and updating another list, so this is a case where a social engineering solution (e.g. "use an Alert Me instead") won't do.

Sorry if this sounds more like a rant, but haven't the SP dev folks heard of CRUD operations? The "D" is just as valid as the "CRU" part. And that whole order-of-operation excuse I read over on technet is baloney. If SP allows me to delete an item from a list, then obviously SP is aware of the request to delete something, and thus should be able to fire off a workflow in response. Okay, enough ranting.

Is there any way of firing off a list workflow based on a list item delete, without it looking like it belongs on thereifixedit.com?

Improve this question
2
  • you're absolutely right, and That workflow does not solve anything, Because to disable the option to remove in General Permits This feature don't work "Create items and edit items That Were created by the user" Moreover, in the calendar of resource reservation does don't work through the elimination of a workflow for bookings with recurrence. Microsoft and SharePoint should provide the user an option to allow starting a workflow to remove an item. – user32934 Aug 29 '14 at 13:35
  • Agreed, this limitation is asinine. – theMayer Feb 27 '15 at 15:05
5

Another option could be to remove delete permissions on the list, add a metadata column so it can be set to be deleted and then add the delete operation to your workflow.

Improve this answer
3
  • I may have to do this; create a separate "delete" workflow, but it galls me to even consider it as an option. Every day with SharePoint seems to be a new day of discovering more incomplete or flat out busted features. Ugh. – Alan M Aug 19 '13 at 16:07
  • This seems like the best approach to me. Here is a tutorial on how to accomplish this: blogs.sharepoint911.com/blogs/jennifer/Lists/Posts/… – bgmCoder Dec 23 '15 at 16:54
  • This is the approach that I would do. Remove standard delete permissions for users. Create a "Delete Item" workflow, which runs under impersonation of a user with Delete permissions. Add that to the context menu. – OneOfThePetes Nov 18 '20 at 12:01
4

I think they made the right call, workflows are for existing items. A deleted item does no longer exist and thereby you can not modify the item or undelete it.

What you could use is an item deleting or item deleted event receiver. Theoretically the event receiver could even start a workflow for you if you need it to, say, send emails or notifications :)

Improve this answer
3
  • 3
    I don't buy it. Especially as a developer. Look at SQL Server, they've had INSERT and DELETE triggers for over a decade. I mean c'mon; to do a delete you have to pass in some sort of row identifier; and you could then expose that same identifier afterwards to subsequent processess (i.e. workflows). Related records come to mind. Or at a higher level, being able to notify people that an item has been deleted so they no longer have to deal with it as a task. We as developers should receive better from Mircosoft. – Alan M Aug 12 '13 at 15:57
  • Well you are free to think what ever you want, as am I, and and I somewhat agree with you but recognizing that this is not the way SharePoint works and that there are multiple other ways to accomplish what you need :) – Robert Lindgren Aug 12 '13 at 16:48
  • 1
    You should use a workflow when you require user interaction with the processing of an item, an event receiver is a better choice when you want to perform a set of actions independent of user input (mostly a consideration of resource usage) -- this is true for all stages of the item lifecycle. My opinion (since we're airing grievances) is that SharePoint should have a way to do event receivers without requiring a solution to be deployed at all, but conceptually the approach is still 'correct' in that the two are different. – John-M Aug 29 '14 at 13:53
1

Just an idea...

Remove delete permissions for all end users. Add a checkbox for Delete Item. Update your workflow to do all your tasks and then in an impersonation step delete the item if Delete Item = true.

Improve this answer
1
  • Funny, its three years since I first asked the question, and there is still no answer other than coming up with a kludge. List item workflows should allow for execution if the list item is being deleted. The "OnItemDeleting()" and "OnItemDeleted()" events exist behind the scenes, so utilizing those as workflow conditional triggers should be straightforward. But nope, we're still stuck with having to bake our own solutions. Argh. – Alan M May 2 '16 at 16:35
0

Lit workflow is exactly what is says: If anything changes on the list, not its contents. By your definition, a site workflow should have site.item.deleted() and site.list.delete() event receivers.

Your problem can be easily solved using item.deleting, where you have all the info, you can query other lists, add new items to the other list, send an email, and even cancel the deletion. Also, with content event receivers, you have much flexibility.

Try to refocus the problem. The problem isn't firing a list workflow, but to do certain things

Improve this answer
5
  • 2
    Yeah, but how is adding something cause to fire a workflow off, but deleting something not? I ask not you, but I ask those at Microsoft. You can rest assured, your local bank is just as interested in withdrawals from your account as they are with deposits. In fact, they're probalby much more interested in withdrawls. A delete is just as worthy as an insert for consideration. It is in SQL Server with triggers, it should be here as well. – Alan M Sep 2 '14 at 22:06
  • My old phone nokia 6170 can search through contacts in names, sirnames, all together. My new android 4.4 doesn't do that. Ok, life's going on. When you add and item in SP, many enries are created in DB, so, a trigger in DB won't help much. I wonder what is the problem you encountered that makes you add this question – XristosK Sep 2 '14 at 22:27
  • Scenario: Self-signup training system where students sign up for classes. Business need: Instructors want notification when students sign up for classes, AND when they drop from a class. Instructor courses are in one list, and in a related list, courseSignups, students sign up for a class. The sign-ups trigger a workflow successfully because they are an add to a list. The drops, though, because they are a delete from list, do not. – Alan M Sep 16 '14 at 20:24
  • You can add an Event receiver onitememdeleting. See: sharepointalex.co.uk/index.php/2010/06/… for the properties. We use it to send an email that this user deleted this record with this metadata. On the other hand, I wonder if deleting is the proper way: you loose information - Maybe set a field as dropoff? – XristosK Sep 16 '14 at 21:45
  • I took a similar solution, a custom action in the Ribbon. But that all (event receiver, custom action) ended up being a lot of C# work for what really should have been baked into the product. I do appreciate your comments, and it may serve to help folks who search this up in the future. Overall, I'm mystified as to why MS does not consider a list delete worthy of being actionable in a workflow. – Alan M Sep 17 '14 at 20:29
0

For historical reference I'd like to add my two cents to the event receiver solution. Knowing event receivers can be problematic to build, debug and implement many times over, I've used a generic approach in Project Server.

Since any item event type seems to contain the same event argument properties, I created a generic event receiver with all the different event conditions.

Within this receiver I added a custom function to start a console app that receives the event and properties in question. With this information I can publish a single event receiver .dll and any time I need to make changes/updates to a handler I simply update the console app without ever touching the receiver definition again.

This doesn't need be a console app but could be a ashx handler web page or multiple ones for each type of event with any type of API you choose (depending on required features)to process the event.

I will be honest to say I have not repeated it in SP yet. I also checked for which properties are available for the different events and found some properties may not be available without setting the receiver to handle them synchronously.

http://blog.ray1.net/2011/06/getting-beforeproperties-and.html

Improve this answer

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.