As I understand, CRM workflow is trigged when a workflow execution request is received on the server. My question is, if there're many reqeusts arrived at the server to trig the same workflow, will there be multiple instances of the same workflow? i.e. is the workflow code re-entrant? This could lead some server side race condition issue.
Thanks~
Workflow can create multiple instances on a same record. For exameple if you define a workflow which will be running when updating picklist field A. Then you update the field 4 times, and you will see 4 running results about the workflow on the record. To avoid it, you can use conditions to check its running context such as trigger when field A equal XXX. Hope these comments can help you. :)
Related
Trying to get my head round a workflow issue in Dynamics CRM 2011.
I have a date dependent recurring workflow that is currently live.
I have realised I need to change it so I go ahead and make the change. (In Dynamics CRM 2011, to do this I have to strip out the condition block and redo it).
Anyway I do this and save it.
Now my issue is that the records that were using the workflow before I made the change are still using the old workflow and not the updated version.
Has anyone come across this bug and if so is there a way to force records use the most recent updated workflow?
This is not a bug, but a feature.
Once you have activated your workflow, the system creates a copy of your Workflow Definition. This copy is the WorkflowActivation instance.
When your activated workflow is triggered, a reference is created to this WorkflowActivation record and your Workflow Instance (an AsyncOperation record) will be executed according to its definition. (Remember, a workflow instance can be live for a long period of time.)
The Original workflow definition can be edited when needed, but these edits will not affect (or harm) running workflow instances, because the latter only depend on their specific WorkflowActivation instance. When the revised workflow definition is activated, the system creates a new WorkflowActivation instance that lives side-by-side with previous versions.
As soon as the last workflow instance depending on a workflow activation has completed, the outdated activation version is automatically removed by the system.
So, you are free to modify faulty workflow definitions, but your modifications have no effect on running workflow instances.
The other answer is correct but doesn't solve your problem. You need to break up your workflow into two workflows: one that waits on your wait condition (the "waiting" workflow) and one that actually does something (the "action" workflow). The "waiting" workflow will call the "action" workflow as a Child Workflow when the wait condition is satisfied.
This way, the "waiting" workflow will always call the latest version of the "action" workflow.
You can also deactivate and edit the "action" workflow without deactivating the "waiting" workflow. If by chance a wait condition is satisfied while you are editing the deactivated "action" workflow, the "waiting" workflow will simply throw an error when it tries to call the deactivated "action" workflow. These "waiting" workflows can easily be "Resumed" after you finish editing the "action" workflow and re-activating it.
I have written a custom work flow which is registered on account entity . I want this workflow to run daily to create tasks. the workflow works fine when i register it on record created . but it does not trigger when i schedule it for every day. like after 24 hours it should trigger automatically by itself
any one can help plz
Two workflows:
Parent who runs on creation and triggers child.
Recursive child who triggers the custom workflow activity.
Parent workflow definition.
Child workflow definition. Extra validation step added to stop scheduled process on condition. Needs to be updated to your needs, of course. Status can be set to Cancelled for clarity.
Notice that the timeout is after the initial execution. This is by design to allow the custom activity workflow to run as soon as the child workflow is triggered by the parent workflow.
As an alternate answer to what #denious is offering, you can use the CRM Workflow Automation Tool. It works on both CRM 2011 and 2013.
This works different in the sense that it does not use Workflow timeouts to accomplish a daily run, rather you set it up as a Windows Scheduled Task (likely on your CRM server) and have it run everyday at a set time.
Setup is minimal and the tool allows you to specify a FetchXML query to retrieve the appropriate records and then a Workflow to execute against the returned records.
A few nice things about this approach:
You can schedule all the tasks to run at the same time (for example 6 AM daily) as opposed to it being run based on whatever time the workflow was originally initiated.
Once the workflow is run there are no lingering workflow instances just running a timeout.
No need for a parent/child workflow setup. You just need a single workflow which does the respective action.
Because it runs on the Windows Task Scheduler you can do things like omit running on weekends where you cannot do this on CRM (without additional tools/rules).
Ultimately, both will accomplish the same thing but this is just another option to consider.
Solved it after spending a week in it...
you should first start it manually by going in a record of the primary entity on which you have added your custom workflow
follow the steps below.
1) Register required steps
2) select record of the entity
3) click on the three ellipses button shown on the ribbon of CRM.
4) click on run workflow
Example
let' say my primary entity is account on which my workflow runs.
1)go to account entity
2)select a record
3)click on the three ellipses button on shown above on ribbon for every selected record
4)click run workflow
5)done
We are having our Sharepoint workflow automattically canceling?? Every once in awhile this would happened. This is the 3rd time out of 20 infopath forms. I am not sure what is causing this and am not sure how to troubleshoot this eiether. It doesnt happend when the workflow starts but rather in the middle of the process which is a lenghty workflow with several steps.
no messages I can see. It just sAYS workflow is canceled. I even tried to run a workflow report and it says report has no data.
I do not see anything in the server logs ?????
now we discovered 2 more workflows that were mysteriously canceled in a another library. it seems sporadic.
these are web forms
I found this
http://support.microsoft.com/kb/2496152
but mine are not canceling immediately and its only on a hand full not all
I think I am going to recreate the workflows. I think something could have got broken in the workflow schema b/c I tried to reuse a list workflow with a newly created form library. It seemed to work for awhile though.
I sort of opened the xml file and changed the list ID and imported it into the worklfow folder with SPDes
I notice they are canceling in the middle of the parrallel Block where multiple tasks (collect data from a user) are running at the same time on all 6 canceled workflows
Any experiences out there? Thanks
It could be worth checking what is written in ULS logs (c:\program files\common files\microsoft shared\web server extensions\12\logs). You will find quite a lot of information there, search for the exact hour/minute/second when it happened.
In my case, I was using a column who’s value would change as soon as the workflow condition was met, thus cancelling itself. So check to make sure your columns are not automatically updated based on another column at the same time the workflow is running.
The SharePoint install is a SP2010 install on a 2008 R2 server. Everything is fully patched. I am running the SP Designer on the SharePoint Server directly.
I have a workflow which is intended to send an email when a new document is created in a custom list. I have deliberately kept the workflow very simple in order to illustrate this problem.
After creating this single step workflow in SP Designer, I click "Check for Errors" and SP Designer reports "The workflow contains no errors".
I then click "Publish" but the Workflow Error dialog is displayed with the message
Errors were found when compiling the workflow. The workflow files
were saved but cannot be run.
Clicking the advanced button reveals more information:
Could not publish the workflow because the workflow configuration file
contains errors
Any suggestions gratefully received
I'll share what fixed it for me - deactivating all workflow features at the site collection level (that is, Workflows, Three-state workflow, Publishing Approval Workflow) and then reactivating the features. I was then able to publish my workflow. This post helped, not sure whether this only works for 365 though, but it's sure worth trying first if you are considering a reinstall.
after googling for quite some time, i think it's an authentication issue. How is your SharePoint set up? Do you use HTTPS for authentication? If so check out this article.
I know this error message from sharepoint. I got this by dealing with multiple lookup fields refering to other lists. Even when I check the worfklow for errors SharePoint says that its all fine but i can't publish it at all.
Try to build a new Test-Site on your Site Collection. Build a Custom Document Library, leave it standard and then set up a new simple workflow just sending a mail.
Fill out the needed fields in mail only using simple values. Send to your mailadress, simple mail subject and simple mail body.
Set the workflow to run only manually.
Try to publish the workflow.
When this is working, then compair to your existing workflow and change your values by trail and error.
After doing a clean install of the OS and SharePoint, workflows are working flawlessly. I can only conclude that the problems were caused by left over registry settings from MOSS 2007. Thanks for the suggestions that people made.
This could also happens if you chage the URL of the web application, all you have do is click the Design button from the library itself.
when changinf the URL from http://server/Site to example: http://server.xx1.net/site, and you try to publish it tries the old url.
what helped in my situation is changing from start workflow automatically to manually.some times answers for critical situation is very easy. hope it helps, many thanks
I ran into this problem and after digging for days and folks suggesting to rebuild the servers, disabling and re-enabling site features, remove previous workflow versions, etc. and trying everything except rebuilding the servers (not practical for clients production environment). I decided to try some tests and found that this issue was only happening on one particular list no matter how simple or complex the workflow was... And when I would check the box for start automatically on item create (or when item changed) it would fail to publish and give the error above, but if I published it with just manually start worked fine. Finally after deleting views and some more testing, I discovered that there was over 240+ columns in this list (I did not create it...) and 50+ workflows set to run on create... Thankfully I have a test environment I built out for the client so I sync'd the Site Collection database back to test environment from Production re-ran my tests and got same error... So what resolved the problem and what was the ultimate cause of the problem, there was to many columns defined in the list and I had to delete several columns to publish the workflow in the test environment. This actually issue translates into the there is a limit in SQL Server on how much data the list can store each type of column takes up so much space read more about it here:
https://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#Column
So what I did in production was worked with my client to determine how to break up the list into multiple lists and have relationships between them, thus moving some of the columns and data to another list (Think database/list normalization)... I hope this solution helps someone.
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.