Sharepoint 2007 - Sharepoint Designer Workflow sending multiple emails - sharepoint

OK, this is a first. I created a workflow for a list in sharepoint designer, its a basic if\else 1 step workflow, if an items been created or modified, it sends an email. After a few revisions (make a change, publish, test, repeat...) a weird issue started, Im now getting several copies of the same email sent to me. Not 2 or 3, but hundreds. After about 20 minutes, they seemed to have slowed down, but Im concerned because I have no clue why they started in the first place.
Were running WSS 3.0, and Im using Sharepoint Designer 2007 SP1. Any help would be greatly appreciated.

Did you create an endless loop by any chance?
That is: Is your Workflow set to execute when an item is modified, and does the workflow modify the item?
Prior to SharePoint 2007 SP2, this will generate an infinite loop:
Workflow starts because the item is modified
Workflow modifies the item
Because the item was modified, another workflow will start
The other workflow modifies the item again
Because the item was modified, yet another workflow will start
Repeat until server crashes
In SharePoint 2007 SP2 this was changed and recursive workflows are forbidden now, but it looks like exactly that is happening with your workflow.
The reason it slows down after a while is possibly because the SharePoint or Mail server is starting to get overloaded.
Which version of WSS 3.0 are you running? Check in Central Administration -> Operations -> Servers in Farm and verify against this table. SP2 is version 12.0.0.6421, any lower version is vulnerable against the infinite workflow loop.

Related

Create a 2010 workflow in Visual Studio 2012 for SharePoint Online

I have a solution in VS2012 with a SharePoint 2013 sandboxed project. I have created some custom workflows in 2013.
What I really need to do is to have an approval workflow to publish content, and send out an email when a new document is approved.
My first thought was to use the OOB approval 2010 workflow and use an event receiver on the list. When an item becomes approved, I would send out an email, but I'm unable to send emails programmatically in SharePoint online.
My second thought was to recreate the workflow in 2013, since I know I can send emails out that way, but it looks like the activities related to content approval were removed for 2013 workflows. I can try and do the approvals via rest calls, but my concern was that my workflow will fire every time the item in the list changes (even if it's not a publish), so I will have to check (in the workflow) if the item is being published or not. This will cause the workflow history for the items to become pretty useless as it will be filled with mostly white noise. Also, as far as I can tell, the checkbox when you create an association for "Start this workflow to approve publishing a major version of an item." does not apply to 2013 workflows.
I believe my best answer at this time would be to create a custom 2010 workflow, but I don't see how I can do that from inside VS2012. Can anyone help me (or maybe suggestion another alternative to achieving my goal?)
You can just turn on the old (2007) approval workflows. It sounds like those might work for you.
This article references how to do that, but in short it is under
Site Settings -> Site Collection Administration -> Site Collection Features -> enable the feature 'SharePoint 2007 Workflows'
Configuring SharePoint 2013 to use legacy workflows
I ended up using an OOB 2010 Workflow and modifying it with SharePoint Designer. Not really the solution I wanted (which was to package ALL of my customizations into a single WSP), but I've spent more time than I should have trying to get it to work.

SharePoint 2010 workflows suddenly does not work

I've been having this issue and been looking for a solution to no avail.
Situation A:
We have a SharePoint 2010 site which contains a list that has a SharePoint Designer workflow. Now everything seems to be working fine, the workflow runs upon item creation and so on, then after quite some time with no one actually editing anything, the workflow just stopped working, no status in the workflow column as well, just suddenly no workflow activities happening in that list, anyone encountered this/knows a solution for this?
Situation B:
We have a SharePoint 2010 site, same as above, we have a list that has a SharePoint designer workflow attached to it. Now this workflow intermittently stops, just suddenly doesn't work upon item creation, no status in workflow columns as well. What happens is that we tried to edit the item and save it again multiple times before it runs. Any idea what's happening?
EDIT: As per checking, I can manually start the workflow.
Sometimes the Workflow Settings can revert to "No New Instances" when you deploy changes to a workflow. You might want to check that.
Otherwise, it doesn't sound like you have a DelayActivity, but it's historically been a place where workflows can hang because of a bug worked around in this blog:
http://the-simple-programmer.blogspot.com/2012/10/sharepoint-workflow-delay-activity.html
You basically have to run:
stsadm -o setproperty -pn job-workflow -pv "Every 5 minutes between 0 and 59" -url http://yoursite
Check your workflow history list. you may get clear picture of what stoping your workflow.
I doubt that this is the reason, but is there a chance that somebody has disabled the Workflows features from the Site settings

Get Context from Workflow sharepoint 2010

Im designing a workflow in Sharepoint 2010 to run whenever users create itens or update itens... my question is how can i know if the item the fired the workflow was created or updated?
Test if (Created == Modified)
If it is true then it should be created, otherwise it is modified.
That is, as long as you are not doing anything fancy with SystemUpdates or timestamps etc.

Workflow initiated by difference in Modified and Current dates - SharePoint

Good Morning,
I'm using SharePoint Designer 2007 to create a workflow for a MOSS site I have created.
What I'm looking to do is have the workflow send out an email if a document in the library hasn't been modified for the past 30 days (and it's Status field is not set as "Closed"), but I'm stumped as to how I can do this.
Any help would be greatly appreciated!
Thanks!
You could try using the "Pause for duration" action (under "Core Actions" when you are adding an action to your SPD workflow).
However, I've worked on something that had a similar requirement and we decided that workflow was not the best option. We have a console application that is scheduled to run everyday and queries the list for "old" items. If it finds any old items, then it sends out an email to the user.

Sharepoint Workflow Fails When First Run But Succeeds When Run Manually

We are using an infopath form that when submitted is supposed to fire off a custom .NET workflow. Basically, the information within the form is used to create a new sharepoint site. What I am seeing happen is that the first time the workflow runs (which is automatic after the form is submitted), the workflow errors out. When I run the workflow manually immediately after it fails, the workflow runs fine.
this.workflowProperties.Item["Client Name"]
I've debugged the issue down to the above line where workflowProperties is of type Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties. The first time the workflow runs, the property listed above (and all others) are null. The second time it is run the client name property is as it should be (populated from the infopath form).
Another important piece of information is that this workflow was working fine for over a year and suddenly started not working correctly a few weeks ago for no particular reason. We were having some permissions issues the past month but I cannot see how that could be related to the workflow issue. The user I am logged in as is a site collection administrator. I use the same user to kick the workflow off manually (which succeeds). I do not think that the workflow runs as the user that is logged in though (when it is run automatically on form submission).
Another interesting wrinkle to the whole situation: there are a total of 3 custom workflows that the application uses. 2 were made in visual studio - one of these works fine and other is displaying the behavior described above. The last was made in sharepoint designer and is failing.
I'm willing to try just about anything at this point. I am on a dev server (which displays the exact symptoms as production) so I can try just about anything.
I'm guessing this has to do with the workflow being fired asynchronously from the commit operation that sets the fields values. Can you try and fetch the item explictly from the list instead of using the Item from the workflow properties. something like the following:
SPListItem l_item =
workflowProperties.Item.List.Items.GetItemById(
workflowProperties.Item.Id
);
i'm not certain, but it may be worth a try.
The other thing to keep in mind is the SPContext.Current object will be null if being called from an EventReceiver, but will be valid if called manually. It doesn't sound like this is the issue, but its something to be aware of nonetheless.
If the InfoPath forms are submitted from a Vista or Win 7 machine, you might face this issue of getting a NULL value for the fields in the InfoPath form. Try adding a delay activity with around 10seconds and see if your are able to get the value of the fields from InfoPath.
Refer to this link for more details: Why does my SharePoint workflow fail when the client is running Vista or Windows 7?
Try looking in your SharePoint Logs.
They are located under the 12-Hive in the LOGS folder - open up the latest and look for something with 'Workflow infrastructure' in it, maybe that can point you in the right direction.
The "solution" was to do an export and transfer to a new server. Basically just use STSADM to do the export operation and then import the same file on the new server.
SEE:
http://sharepointdogs.wordpress.com/2008/07/30/content-migration-or-backuprestore-in-moss-2007/
I was on the phone with Microsoft Support for hours on this issue - transferring to a new server would be my recommendation for anyone else that might encounter this problem.

Resources