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.
Related
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
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. :)
I need to create a custom workflow for use in Sharepoint 2007. The crux of it is that a workflow task will be created in SP when the workflow is started and if that task isn't complete in X minutes, an email should be sent reminding the user to complete the task.
Is there a mechanic in WF that can handle this? From what I'm reading (totally new to WF) it doesn't appear there is and I really need some external process that checks all task items regularly and notifies accordingly. It doesn't appear I can handle this solely in a WF.
Is that right?
If you're using SharePoint designer to create your workflow, then there is no easy solution to this.
But if you're make a "real" workflow using Visual Studio then the solution is something like this:
Create Task
Code (Calculate when to send e-mail)
While (Task not completed/deleted)
Listen (With 3 branches)
Task Modified
Code (Check if completed)
What else you might want
Task Deleted
What should happen in this case
Delay
Send E-mail
Code (Calculate new time to escalate)
I have a workflow created in Sharepoint designer that works fine when manually triggered. I want it to trigger when a new ticket is created and when an existing ticket is edited. I have tried everything, but it makes no sense that it works when manually triggered, but does not appear to trigger when tickets are created/modified. Any help would be appreciated.
While creating a work flow (first screen) you can see three check boxes
Allow this workflow to be manually started from an item.
Automatically start this workflow when a new item is created.
Automatically start this workflow when ever an item is changed.
You might have choosen the first option only. So that you need to start it manually. You have to opt the three options
also what do you mean "I have tried everything".
Is there any 'out of the box' feature in SharePoint to allow you to schedule a workflow?
No there is no OTB feature to do that, but depending on the workflow you might be able to fake it.
If it's a SharePoint Designer workflow you've created that you want to run at certain intervals. Then you can make the following changes to it:
Make it run automatically when the
item is changed.
When it's done with the real
functionality then make a delay and
after the delay modify the item and
stop.
A new instance of the workflow will then spawn due to the modification