Topic: ‘Workflow’

Excited as I am about the new dialog features available within the new 2011 version of Microsoft Dynamics CRM? If so, you’re going to love the newest features available with UR5 (aka Rollup 7 for those of you using the Online version), including the following:

• Smart Form experience at Runtime (insanely helpful for tailored call scripts)
• Enabling hyperlinks to CRM Records (NOTE: this is available in workflow, too), and
• More CRM Data types, such as Date, Date Time, & Lookup type attributes (HUGE!)

Check out the Microsoft CRM Team blog post for more detailed information on these new & robust features.

Still on the Dynamics CRM 4.0 version and want to kick it up to the Dynamics CRM 2011 version? Visit our DynamicsCare Dynamics CRM Upgrade landing page for more information on how the 2011 version can greatly improve your customer relationship management experience.

Discover the benefits of workflow development and learn how to utilizd the wizards and additional features of CRM 2011 workflows.

When implementing CRM, it is not unusual for a request to surface that requires datat creation based upon a certain action.  Usually it is something like “create an Activity record” or “update another entity based upon a change in a record.”  Plugins, and sometimes workflows, can both handle this situation. 

Workflows are a basic and simple way to go. However there is a limitation – workflows cannot update multiple related records (e.g. child records of a parent record).  Plugins on the other hand are fully capable of getting the job done. When you are in a situation where either functionality can handle the job, a question surfaces: “Which one do you use?”  Read the rest of this entry »

The creation of a timeout inside of CRM 4.0 is a little bit tricky. It is a relatively simple task to complete; however finding it is somewhat difficult without some guidance on the first attempt.

After you create your workflow, you will be adding a Wait Condition – this is basically going to force the workflow to “wait” for a predefined amount of time before moving onto the specified action items below the wait step.

To add a wait condition, you will need to select the row to which you want to add the condition, and then select the Add Step option.

After you select Add Step, select Wait Condition.

Once you select “Wait Condition” in the “Add Step” dropdown menu, you will select “<condition> (click to configure).” This will open a new window. From here, you will select the following properties:

• 1st property (dropdown): Local Values, Workflow
• 2nd property (dropdown): Timeout
• 3rd property (dropdown): Equals
• 4th property (date range): Time Amount, for example, 7 days
• 5th property (dropdown): select Duration value

Here is what you will see once you finalize the Duration property. This is exactly what you want to see in order to have a timeout. Click Save & Close when you’re done.

Once you select Save & Close, the “Wait until…” option disappears and is replaced by “Timeout until.” This is how you will know for sure that you did this right. From here you can add your final steps to the workflow, be it an email notification, a record update, or an automatic assignment.

TIP: If you have additional actions specified below a wait condition, and then you select a timeout feature, your additional actions will be REMOVED. Always specify the properties of the timeout, even if you’re not sure about the date range, BEFORE adding action items below.

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.