Advanced Find is a foundation skill in Dynamics CRM, and it comes in handy in pretty much every aspect of using, configuring and customizing the platform. Locating records, maintaining marketing lists, creating reports, customizing views, exporting to Excel, sharing records, creating duplicate detection rules, doing mail merges…and lots of other things all benefit from a solid working knowledge of Advanced Find. One of those other things is workflows, another of my favorite topics, and here are a few examples of how you can use Advanced Find to figure out what’s going on with your workflows.
Certain kinds of records have an attribute you can use in Advanced Find to filter on whether the records were created by a workflow. These “certain kinds” of records are the activity record types (with the exception of campaign response), and the so-called “activity pointer” record. To verify this, open Advanced Find (click on Advanced Find on the global toolbar) and select any of these in the Look for drop-down list: Activities, Appointments, Email Messages, Faxes, Letters, Phone Calls, Service Activities, and Tasks.
OK…so why do you care if something was created by a workflow? Well, if you use automatic workflows a lot it’s easy to take them for granted: they happen automatically as part of a process and you don’t have to think about them a lot. Which is good, to a point. But there’s a fine line between taking a process for granted…and forgetting about it entirely, which is where this little trick comes in handy.
Here’s an example, where I’m filtering the generic “Activities” record type for just the ones that were created by a workflow:
When I click Find, here’s what the results look like:
Notice those oh-so-polite thank-you e-mails? Those are all auto-responders: sent out by an automatic workflow after a web site visitor fills out one of my Web2CRM forms. Auto-responders are nice and everything, but if you want to make sure they’re getting the proper post-auto-responder e-mail attention, you might want to save an Advanced Find view and maybe use it to create a report you can run on a regular basis.
Here’s a slightly revised filter:
And here are the data:
You can save a view like this with a name like “Auto-Responder Thank-You E-Mails” and use it as the source of data for a report. Add the “Regarding” field as one of the columns and you can see who the e-mails went out to and spot-check subsequent follow-up activities.
A running instance of a workflow is referred to as a “System Job” in Dynamics CRM, so if you want to keep tabs on workflows that are running or have run, you can select System Jobs in the Look for drop-down, and then filter on System Job Type, like this:
Depending on how much you use workflows, a filter like that might return a lot of records, so I generally filter it down a little further, often with workflow system jobs using the “status reason” attribute, something like this:
For system jobs of the workflow kind, status reason values of “waiting for resources” and “waiting” can be red flags…especially if they started, say, more than three months ago. Here’s a good use of the “Started On” attribute with the Older Than X Months operator:
Records in the result set are good candidates for some workflow forensics:
Why does a workflow get stuck in the “Waiting place“? Here are a couple common reasons I encounter from time to time:
- A workflow might have a logical flaw. For example, if a workflow is on a Wait condition and the record the workflow’s running on gets closed, what happens if the workflow doesn’t have built-in logic to cancel itself? In cases like this one, after you identify the records you can select them and select Cancel from the More Actions menu. You will also want to fix the workflow: unpublish it, make the changes, and publish it again. This won’t help any records it was already running on, however, since it’s still the flawed version of the workflow that’s running on them!
- Or how about if the workflow’s trying to do assign a record to a user who doesn’t have Read privilege to that record type? That will do it too. This can be confusing, since it’s easy to assume that an automatic workflow written and owned by a System Administrator can “do anything” (since as we know an automatic workflow runs in the security context of the workflow owner). But just because you’re a System Administrator doesn’t mean you can assign a record to a user who can’t own those records! This can be a good place to see how Resume works rather than Cancel. If the problem was insufficient privileges and you modify the user’s security role, you can resume and watch the workflow try again.
There’s a general point we can make here, on this issue of when you can Resume and when you have to Cancel when it comes to Dynamics CRM workflows stuck in the waiting place:
- If the problem is caused by something outside the workflow – like a security role problem, or trying to modify a read-only record – you can fix the problem, then Resume the workflow.
- But if the problem is with the workflow itself — and you have to unpublish, modify and republish what will be a different version of the workflow – you’ve got to Cancel.
Only a true Dynamics CRM workflows geek (or the mother of one) could tolerate a heading like that one, so if you’re still reading, I thank and congratulate you! (Mom, it’s a little late tonight, but I’ll call you tomorrow!)
But if you want to know every opportunity that has had a workflow applied to it, or every workflow that has ever been run on an opportunity, this is a handy trick. I’ll leave you with the following two screenshots, and make it a homework assignment to let me know if you have any questions.
All workflows that are running or have been run on opportunities:
All opportunities that have or have had workflows running against them:
