I have a flow that processes calendar updates as part of an Out of Office tracker, saving the items to a SharePoint list. The flows generally work well, until a time comes when someone updates recurring items, and the flow gets hammered with all the updates for that calendar event. With one update, it usually works ok, but if I get two or more, the flows stay in a running state and never finish. Will they ever complete? Is this a throttling issue?
Related
I'm wondering how long a Dynamics CRM workflow will stay in a Status Reason of "Waiting" before it times out/gets cancelled automatically?
I have a workflow for "Renewal" Opportunities with the following step: "Wait until Today's date >= 3 months before Renewal Date." Then, the record is updated. I'm worried that if the workflow has a status of "Waiting" for too long, it will cancel automatically. Will this be an issue? If yes, what is a better way to handle "Renewal Opportunities", so the Opportunity Name gets updated with the word "Renewal" 3 months before the date in the "Renewal Date" field?
Thanks!
It will wait indefinitely. But... as someone who has written products that rely on waiting workflows, I can say that there can be issues. Perhaps most prominent is the risk of the workflow getting cancelled before its trigger date - not "automatically" but by a user or user-defined process.
One client has routines that cancel waiting workflows on a regular basis. That broke everything all the time until we moved their scheduling out of workflows to an online scheduler.
In general it's fine to rely on waiting workflows that are scheduled months out, but it's also prudent to have a mechanism to confirm that they're operating and recover when they're not.
Aron did a good job of tackling the first part of your question.
If yes, what is a better way to handle "Renewal Opportunities", so the Opportunity Name gets updated with the word "Renewal" 3 months before the date in the "Renewal Date" field?
1) Create a procedure:
Often a manual procedure is more cost effective and reliable than developing automation.
- Create an Opportunities Pending Renewal view which shows all opportunities where the Renewal date is within X days of today.
- Create a Renew Opportunity workflow
- Put in place a process where by a user regularly (once a month/ once a week?) opens this view and runs the Renew Opportunity workflow.
This is a good option if the renewal does not need to occur on an exact date.
2) Have an external application launch the workflows:
You could write a lightweight scheduled application to carry out this operation. If you take this route, I recommend keeping as much of the configuration in CRM as possible by having the application execute over the results of a CRM view and kick off workflows to carry out the renewal action. That way when your business decides to change their rules (e.g. different renewal period) you just update the view criteria or workflow.
This is a good option if you have in-house dev power and if there are many such workflows that you can leverage your scheduled application to handle.
3) Have a plugin launch the workflows:
This is my personal preference. Same as Option 2 except rather than using a scheduled console application you let CRM host and schedule the job. Create a custom scheduled task entity, and set up a workflow which waits for some period (e.g. 24 hours) then creates a scheduled task record. Add plugin logic which fires on-create of scheduled task records, which carries out the same actions from option 2.
This is better than #2 for several reasons:
- Does not require external hosting, no integration concerns
- The job can be triggered manually simply by creating a scheduled task record
- You can add result logging to the scheduled task record
Other thoughts:
I won't pass judgement on whether the above options are "better" than waiting workflows, they all have different strengths and weaknesses. The Async service is much more reliable that it was historically, but I personally still try to avoid using workflow which wait for extended periods of time, primarily for system complexity and performance reasons. If you need automation and don't have in-house developers, then your best option probably is to set up waiting workflows.
I'm looking at the Field Service module of Dynamics 365. I'm trying to block out an employee's time on the schedule board by creating a time off request.
I can create the time off request, but as soon as the object is saved, the system automatically deactivates it.
The system will reported success when Approving a time off request but I can't see any changes in the data nor any records created in the audit summary. If I try to Active a time off request, the process fails due to a Business Process Error:
Microsoft.Xrm.Sdk.InvalidPluginExecutionException: Time off request records can't be reactivated.
To the best of my knowledge, there aren't any process changes to time off requests (but I'm unsure how to confirm this). From everything that I've read, this should be a fairly straight forward process so I'm not sure where to look next.
This page from the documentation is a good example of what I'm trying to do. It's failing on step 3 of "Approve a time-off request".
I've tried creating time off requests:
in the past
for tomorrow and more than 2 weeks future
of duration lengths from 2 hours through 2 weeks
for various user accounts
The time off requests are not conflicting with booked resources.
Any advice on what I could look into to determine if someone modified any processes / workflows associated with time off requests? Or is there something that I'm not doing that I should be?
I've learned that Microsoft's documentation is not complete and there was a bug.
Additional info on how Time Off Requests are used
There are two views of Time Off Requests (TOR) available to managers: Active and Inactive.
Active TORs: Lists TORs that a manager needs to approve
Inactive TORs: Lists TORs that have already been approved (i.e., the request itself has been dealt with)
Bookable Resources have a Time Off Approval Required property. When true, TORs created for the user are Active; when false, TORs created for the users are automatically moved to Inactive.
All Inactive TORs should appear as grayed-out boxes on the Schedule Board. If you attempt to Activate an Inactive TOR, the following error will correctly be reported:
Microsoft.Xrm.Sdk.InvalidPluginExecutionException: Time off request
records can't be reactivated.
Field Service Bug
Additionally, we experienced a bug that prevented Inactive TORs from being grayed out on the Schedule Board. I'm not sure if this was a process error or a client-side style issue.
We observed the bug in Field Service 6.1.0.1462. Upgrading to 6.2.1.38 resolved the issue and allowed Inactive TORs to show up on the Schedule Board.
I have a workflow that runs when an entity is created and it creates two other entities and puts them on a queue. It then waits until each entity's status reason is set to done. After which is continues.
Basically two teams will work an order and then it will continue processing after both teams are done.
Most of the time it works. However sometimes it waits forever. I'll re-active and re-resolve the other tasks, but it just never wakes up.
What can I do? The workflows aren't really powerful enough for me to have it poll with a timeout (there are no loops). I'd like to avoid on-change plugins for these other entities to get workflow behavior all scattered about.
Edit:
Restarting the CRM services (not sure which did it, I restarted them all) allowed the workflow to resume. However, I'd still like to know how to make this more reliable.
I had the same problem (and a lot more) with workflows in CRM 2011 and decided not to use them (except for very special purposes).
The main reason is because of their very limited error handling. Another reason is that it is inconvenient to put them under source control. Another reasons are: Worflows cannot run offline and user impersonation is also not supported. For a comparison look here: http://goo.gl/9ht1QJ
Use plugins instead of workflows, then you have full control.
But keep in mind that plugins (unlike workflows) are not designed for long running tasks.
So they have a default max execution time of 120 sec and are not stateful/persisted. But in most cases (and i think also in your case) that is not a problem.
Just change your eventing a little bit:
Implement and register a plugin step for: entity is created and it creates two other entities and puts them on a queue
Implement and register another step: entity's status reason is set to done, query for other entity and check status, if done continue processing
If you really do not want use plugins for you business logic you can consider implementing a plugin which restarts/resumes faulted workflows.
But thats not a very nice solution.
I'm trialling CRM 4.0 and have noticed that if one of my contacts sends an email then it sits in the queue for an hour before it is also copied into the contacts history.
Is there a job or workflow controlling this?
Can it be sped up?
Sounds like the workflow behind it isn't running quickly enough.
If you go to Administration and Workflow admin (I think thats what it's called) you can change the frequency of the workflow to a shorter interval.
Is it possible to schedule pulgin on CRM.
I ‘m trying to create a reminder task activity for an opportunity entity if no there has been no activities in the last week. I would like this to run every week.
Thanks in Advance.
Though there is no such thing as a recurring workflow in Dynamics CRM, you can simulate this behaviour by creating a Workflow Rule that
Gets fired upon creation of the record
Checks a condition
Conditionally does something
Waits for n days/hours/minutes
Calls itself again
Don't forget to mark the rule as "Run as a child workflow".
I think perhaps a better approach would be to build that functionality into a workflow? I have not been doing much CRM lately, but I have implemented what you described, in Crm 1.2 back in the day. This turned out to be very useful for reporting as well, pulling reports of what sales staff makes it a habit to not follow up on opportunities.
Best Regards
Rihan
I would recommend to utilize SQL Server Scheduled Job. Although workflow can be used for this problem, but waiting-state-workflow is considered application consuming.
The reason is because the waiting-state-workflow is held in the memory, and it needs to be validated against certain timing condition periodically. In your case, it needs to periodically calculated whether it has exceed one week or not, and if it's yes, it will upload the waiting-state-workflow from the database to be executed.
Regards,
hadi