Topic: ‘Workflow’

Workflow is one of the most desired functionalities inside of CRM implmentations, and one of the driving forces behind the utilization of CRM. The Microsoft CRM Team Blog has posted some great information regarding workflow best practices on their blog.

Click here to read the article.

I recently helped create some workflow logic for a client that encompassed a Lead Escalation process-flow.

Basic Summary: A person is notified at the beginning of the Lead stage – after record creation – that they have a new Lead (this is the trigger of the workflow). They are then allotted 48 hours to follow-up with that particular Lead – in the form of saving a Task record (created by the workflow at fire) as completed. If they don’t do anything, they get notified after 48 hours – an email is sent to them (and their manager) telling them to get with the program, and they have 24 more hours left to do it. After 24 more hours, if they still haven’t followed-up, another email is sent, the Task record is deactivated, and the Lead record is reassigned to a neutral employee for redistribution.

Reasoning: This workflow job will hopefully move Leads through their initial stage at a much faster rate. Lead shouldn’t be kept as “Leads” for a long time – less than a week before you either know they have potential or know they’re crap. However, how can you filter them down between good/bad unless you follow-up with them and see what kind of business could potentially ensue?

I’ve outlined some steps towards testing the effectiveness of the particular workflow that I’ve created. Its one thing to spend hours creating a workflow (or minutes if you’re just that good) that you think looks glorious. But it’s a whole other thing when it comes to troubleshooting. How do you know it’s doing what needs to be done? There have been plenty of times where I’ve created a workflow job that seems perfect, and the logic just isn’t right. If you don’t troubleshoot it properly, days or weeks of lost profitability could result (I’m not trying to being a drama queen; workflow ineffectiveness just makes me feel nauseated).

I’ve included some screenshots that should help illustrate what needs to be examined in order to know that this workflow is doing its job (some of these steps will be handy with other workflow varieties as well):

1. TRIGGERING THE WORKFLOW: To make sure the workflow fired, go to the Workflow area under the Details section of the respective Lead. You should see a workflow job listed in the listview that has the correct date and time on it.

Possible Status Reasons: “What do these mean?”

1. WAITING FOR RESOURCES – it’s going to go, you just need to give it a minute. If it stays there for a while, there’s could potentially be an internal issue.
2. WAITING – the foremost situation regarding this status reason is that there’s a WAIT CONDITION in the workflow that is requiring this workflow job to hover in this state, before it can most onto the other steps in the workflow (in the case of the Lead Escalation workflow, there’s a TIMEOUT WAIT CONDITION that is requiring the workflow to basically hover for 2 days. It will wait for exactly two days, and then resume. See the screenshot in Number __)
3. IN PROGRESS – it’s going; it’s just not done yet.
4. SUCCEEDED – regardless of how self explanatory this seems, it merely means it’s done. Whether or not the logic is working to its best ability or even doing what it needs to do – it’s not being taken into effect. You will need to double check two things: the results of the job (did the required actions happen?) and the SYSTEM JOB, seen later in this email.
5. CANCELED – means you canceled it manually, or it cancelled itself through a clause in the workflow (“If blah blah happens, cancel workflow job.”)

2. DID WHAT NEEDED TO HAPPEN, HAPPEN? You need to make sure that any records that needed to be created are created, any records that needed to be updated are updated, and any other actions that need to be taken are taken. Workflow’s very good about this (there’s usually an obvious reason it wouldn’t work), but as part of the troubleshooting phase, it’s imperative that you double check to make sure that it’s doing what is necessary, mainly to make sure you created it right. Below is the listview showing the Task that was created after the Lead was created.

a. Note the due date – two days after the workflow fired. This is important as well. If you have a due date that’s on the form, make sure it’s reflecting the correct information. If it’s not, you will need to go back in and rework the data fields on the Task creation clause.

b. Double click the record and check the data fields – make sure they’re pulling through properly.

3. VIEWING THE SYSTEM JOB: You will also need to look at the system job. Go to the Workflow section under the Details area, and double click on the particular job you are testing. As you can see below, you will see when it fired (9/9/2009, 3:34 PM), the reason it started (Record was created [this is the trigger], or it can display a manual start – meaning you clicked on a button that says “Run Workflow”). If the workflow job is either Succeeded or Canceled, you will see a datestamp in the Completed On field.

As you can see, the workflow job illustrates the progress of the workflow job – what has happened, why is it hovering (if that’s the case), what has yet to happen, etc. If you come across a little red circle with an X in the middle of it, this means something went wrong – there’s something potentially wrong with the logic, someone doesn’t have an email address that’s supposed to be getting an email, a particular record doesn’t exist in the system anymore (if this particular record is deleted from the system before the job is finished, the little red X will show it’s pretty face), etc. There are several reasons why this could happen. Sometimes it explains what’s wrong, but other times the message given is a little vague. Workflow likes to make you investigate.

When it comes to the TIMEOUT functionality – merely looking at this job and saying “Yay, it’s timing out” isn’t really the best. You need to look at the SUSPENDED JOBS LISTVIEW. This is located in the System Jobs area. See the later in the post.

4. SYSTEM JOB LISTVIEW: You want to look at the SUSPENDED JOB LISTVIEW in order to see more information on jobs with timeout functionality. See the screenshot below for location.

Tip: the SUSPENDED SYSTEM JOBS listview is really handy as well in order to see if there are a lot of jobs that are WAITING FOR RESOURCES. If there are numerous jobs in this state, and it doesn’t look like their “waiting” is paying off, there’s most likely an internal issue (i.e. you import 250,000 Leads a day into the system, and a workflow fires every…single…time. Yes workflow is doing its job – it’s firing. No it’s not going to actually work – too much of a good thing is indeed, a bad thing. It will hose up your system.)

You’ll want to look at the POSTPONE UNTIL date (see below). This will let you know when the workflow will wake back up and continue its course. If your timeout expression states two days and it’s postponing for two days – hooray. However, if it says something like 12/30/9999, there’s something wrong with the timeout expression, and the workflow logic needs some TLC. 

PART I

I recently encountered a situation where imports and workflows in CRM could not be completed. The initial problem was recognized when data imports were being defined as “Submitted”, but not “Completed” in the CRM interface. I initially thought that the system was running slow, but after it took a full day to import two lead entities with no more than eight fields, I realized this wasn’t the case! At this point I made sure that the appropriate MS Rollups were applied and the CRM server was rebooted, in the hopes that these actions would somehow solve the problem. They didn’t. After confirming that the data import maps were correct, I noticed that workflows weren’t working either. I then checked the MS CRM Async Processing Service on the CRM server. For those of you who might not remember, the Async Process handles the processing of queued Asynchronous Events; i.e. data imports, workflows, system jobs etc in CRM(below). I checked to see if the Async Service was running, and of course it was. I checked that the “Log On” was set to Local, it was, and then I stopped and restarted the service. I tested a data import, and… nothing. Still stuck. At this point, I enlisted the help of those at MS, and here as what we found.

At first (to recap) all system jobs were in a waiting state and nothing was being processed. We looked into IIS and noticed that the CRM website was set to an IP address. (For instance, the CRM web IP) Since this was true, the Async service was not able to communicate to the CRM website. Since the AsyncSdkRootDomain was blank, it was trying to communicate to CRM by using the OTB loopback address of 127.0.01. Since the website was set to an IP address, it was not able to communicate to the loopback address. To define whether or not the AsyncSdkRootDomain has the correct value, or in our case ‘a’ value, run the following SQL query against the MSCRM database:

Select NVarCharColumn, * from DeploymentProperties

From this query, we are specifically looking for the value of the NVarCharColumn for the ADSdkRootDomain and ADWebApplicationRootDomain in comparison with the AsyncSdkRootDomain. When we realized there was no value for the AsyncSdkRootDomain, we went through the following to correct the issue. This is documented by MS in KB article 950416, which can be found here: http://support.microsoft.com/kb/950416

1. Downloaded the Deployment Configuration tool found in KB article 949079 (http://support.microsoft.com/kb/949079/).
2. Extract the Deployment Configuration tool, and put it in the location on the CRM server.
3. Back up the MSCRM_Config and OrgName_MSCRM databases*. �

4. At command prompt, path out to the directory that contains the microsoft.crm.deploymentconfigtool.exe file, and then run the following commands to correct this setting:
microsoft.crm.deploymentconfigtool asyncsettings update -sdkrootdomain:Peakcltnts32:5555
5. Reset IIS. To do this, click Start, click Run, type iisreset, and then click OK. �
After doing this, we were able to get the System Jobs running. Success!!!

Part II coming soon!

*This solution involves making changes to 1 or more databases. It is not suggested that changes made to a database without first making a backup of the database. If possible, alternatives such as a MS Hotfix or MS rollup should be used to try to solve the issue, before modifying a database. If you do decide to modify the database, it is suggested that the modifications are made by an IT Director, Technical Specialist or MIS department. Serious problems might occur if you modify the database incorrectly. Be sure to backup the database before making changes. Any problems might require that you rollback your databases and even result in the loss of data records. I.B.I.S,. Inc. cannot guarantee that these problems can be solved. Modify the database at your own risk.

A client was experiencing an error when creating a workflow that will have the functionality of sending an email.  When you click the Set Properties button, an exception is thrown.  Screen shots from the UI are below.  The Event Log shows:

“InvalidOperationException: Operation is not valid due to the current state of the object.”

I found this answer and it works.

This is a known bug in Microsoft Dynamics CRM 4.0. It occurs on an organization migration whenever reports exist using Notes as the main entity. There is a hotfix in the works.

Current workaround:

This will find any reports using Notes for the main entity:

SELECT * FROM ReportEntity WHERE ObjectTypeCode = 5

If a GUID is returned, it means there is a report that is using Notes as a primary entity. In that case, do the following:

a. Copy the GUID id.

b. Open a report and then Press F11 twice until you get the address bar.

c. Replace the report guid with the one from the Query and press Enter.

d. In Microsoft CRM, select the Report from the list and then Click Edit Report on the Menu bar on top.

e. Go to the Categorization Section and the Related Record Type line, click the “…” button and add value. Save the report.

f. Open the same report and then remove the Related Record that you added. You should be able to create the workflow with email now.

Sometimes an Account may not have a primary contact associated with it, and it’s difficult to know exactly who to contact when you need to get in touch with an Account. Workflow can take away the manual task of actually associating a primary contact each time a new Account is created. Follow these steps to create a workflow to automatically set the primary contact of an Account:

1. Navigate to Settings on the left-hand side of your screen, and then click on Workflows. Click on New to create a new workflow. In the Workflow Name area, type in Set Primary Contact. Choose Contact as the entity in question, and leave the Type as New blank workflow.

2. When the Workflow box opens, keep the default settings for Scope and Start When. Click on the area that says Select this row and click Add Step.

3. Type in a description for the check condition that you are using. In this case we want to check and see if the parent account has a primary contact. After you have typed in a description, click on the blue hyperlink that says <condition> (click to configure).

4. Once the new window opens up, you need to specify the workflow condition. Choose Parent Customer (Account) as the first selection. Next, find Primary Contact, and lastly select Does Not Contain Data. This means that we are checking to make sure that the parent customer does not have a primary contact already. Click Save and Close.

5. Select the second row of the If statement and click Add Step. Select the option Update Record.

6. Type in a description for the Update Record condition. For this one, we are going to Set the Primary Contact of the Parent Account. Click on the button that says Set Properties.

7. When the window opens, the Account form will be visible. Select the field that says Primary Contact.” The Form Assistant should be visible on the right-hand side of the window. If it isn’t there, click on the small button with an arrow pointing to the right.

8. Make sure that the form assistant is visible on the right-hand side of the window. The Operator and Look For values are defaulted in the form assistant. Click on the Add button, and then click OK. This will place {Contact(Contact)} in the Primary Contact field. Click Save and Close.

9. After you have saved your workflow, remember to publish it by clicking the Publish button on the toolbar at the top of the workflow window.

10. In order to test the accuracy and effectiveness of your newly created workflow, create a brand new Contact for an existing Account that has no Primary Contact. On the Contact form, fill in the field that says Parent Customer. Save the contact, and then open the Accounts listview and open the Account. You may need to wait a few minutes to make sure that the workflow has had enough time to process. When you open the Account, the Primary Contact should be populated for you with the Contact that you created.

11. If the Primary Contact has not shown up in the Account form yet (and you’ve waited a little bit), navigate to the Workflow section of the Contact form. This will allow you to visualize the progress of the workflow you have created. If it does not say Succeeded, you may need to refresh the listview or even give it some more time.

I recently promoted a couple of new workflows, but they were not firing correctly. My first thought was the Asynchronous Service was stopped or may need restarting. My assumption was correct; the Asynchronous service on the CRM application server had stopped. 

I restarted the service and tried the workflow again, but it still did not fire. Turns out the Asynchronous service had shut down again so I take a look at the event log and the following error was repeated multiple times.

Open the image below in a new window and maximize to view:

After researching the problem, I stumbled across this KB Article. 

Based on the information in this article, I checked the Servers table in the MSCRM_Config database and the SQL Server Name did not match the name returned by the Select @@SERVERNAME statement. So, I corrected the Server Name in the Servers table to match the SQL Server Name (Case Sensitivity). I then restarted the Asynchronous Service and workflows fired correctly and the above error did not appear in logs.

I recently had a request to add two new fields to the Case form: Closed By and Closed On. In addition, when a Case gets resolved, they want the two new fields to be automatically populated. The values of the Modified By and Modified On fields contain the data we need to populate the two new fields. So all we need to do is copy them when a Case is resolved.

It sounded easy enough. So I created my workflow to do just that. When the Record Status changes, I set the Closed By and Closed On fields equal to the Modified By and Modified On values. Upon running the workflow, the fields never updated. The reason is that resolving the Case marks all fields on the form as read only.

The solution I came up with was to first check if the Case was Resolved and to check and see if the Closed By and Closed On fields were blank. Then change the Case back to In Progress, set my values, and change the status back to Resolved.

Here is a screenshot of the workflow:

How your organization decides to manage your lead flow is unique to each business. Below is just an example on how this process can work. We are not trying to say this is the best way – or the only way – but just an example. We LOVE the new workflow in v4 and our good friend Ben Vollmer and IBIS had some fun building out some other cool things. You can read about that on his blog here.

So your organization just imported a bunch of leads. Those leads cost money. The people that screamed for those leads will definitely follow up in a timely manner, right? I’ll say sometimes.

While people have the best intentions, they are busy. How can the organization keep track as to whether or not the leads are being pursued? The answer is WORKFLOW.

Here is a little background for this scenario. The leads come in and are imported by marketing and assigned to the marketing person. The leads are then reassigned manually to various reps. Due to this process, our workflow will fire on Record Assigned. Once a lead is assigned, we would like to notify certain CRM users if the modified date does not change in the next two days.

This looks simple enough, especially since we can have the workflow sit in timeout for an allotted period of time.

When creating this workflow, there was one thing that had me hung up. That was how to compare any time values to the current time to determine elapsed time. The secret turned out to be the Workflow: Execution value. Workflow: Execution value represents the time that part of the workflow is running which is fairly close to right now.

Here are the step by step instructions.

1. Open the CRM web client, click Settings in the lower left hand corner, and select Workflow in the top left hand side of the screen.

2. Click New. Give your Workflow a descriptive name, select the Entity it will run against, and leave the radio button set to New Workflow. Then, click OK.

3. On the workflow page, change the scope to Organization so the workflow will run against all leads and set the “Start when” value to “Record is assigned”.

4. Select the row with the label “Select this row and click Add Step” and click the “Add Step” button. From the list, select “Wait Condition”.

5. Enter a Description for the step and click <condition> (click to configure).

6. In the first picklist, select “Workflow”. Click “Select” and pick “Timeout”. Click the next “Select” and pick “Equals”. To enter a value, we will be using the Form Assistant pane to the right. We would like to wait 2 days from assignment so we will select “2” for days, “After” instead of Before, “Workflow” from the Look For picklist, and then click on “Execution Time”. Once you click on Execution Time, you will see the value populated for you. Click Save and Close. Your workflow should now look like this.

7. Select the next row, click “Add Step”, and choose “Check Condition”. We will now check if the Lead has not been Qualified or Disqualified. To make this easier we will check that the Lead Status does not equal “Open”.

8. In the first picklist, select “Lead”. Click “Select” and pick “Status”. Click the next “Select” and pick “Does not Equal”. Click the […] button and choose “Open”. Click Save and Close. Your workflow should now look like this.

9. If the lead is not open we want to stop the workflow. Click the line below the If statement and click Add Step. Select Stop Workflow and select “Canceled” from the picklist.

10. Select the If statement line, click the Add Step button and select Conditional Branch.

11. Now we need to set the condition on the “Otherwise, if” line. Click the <condition> field.

12. In the first picklist, select “Lead”. Click “Select” and pick “Modified On”. Click the next “Select” and pick “Is Less Than”. To enter a value, we will be using the Form Assistant pane to the right. Since the Modified On date got changed when the lead was reassigned, we can check if the Modified On date is less than 1 day 23 hours and 59 minutes. Select “1” for days, “23” for hours, “59” for minutes, “Before”, “Workflow” from the Look For picklist, and then click on “Execution Time”. Once you click on Execution Time, you will see the value populated for you. Click Save and Close. Your workflow should now look like this.

13. Select the next row, click “Add Step”, and choose “Send E-mail”.

14. Click the “Set Properties” button to fill in the appropriate fields on the email that will be sent out. The Regarding field already has a link to the related lead. I typically have the email sent from an administrator account. The recipient can be the rep, the rep’s manager, CRM users, etc. I don’t want to go into details on how to use Dynamic Values but they are pretty useful.

15. Please note that you need not fill in every field. Once you are done, click “Save and Close”. You workflow should now look like this.

16. Now all that is left to do is to save it and publish it. You will notice on the toolbar that you can publish from here. I made it a habit to save the workflow first, then I publish it.

17. Click “Save and Close” and then with your new workflow selected, click “Publish”.

18. Your workflow is now active and will fire whenever a Lead is assigned to another user.

Some Additional Notes:

When checking the lead modified on field against the workflow execution time, I chose not to use Less Than or Equal To 2 days because I wanted to leave a little wiggle room for latency in the workflow process running. It is possible that it would work but I figured that the odds on a rep getting the reassigned lead, calling the lead, and saving changes to the record in under 1 minute was slim to none.