Friday, September 26, 2008

Workflow "Increment by"

There is a lot of functionality to workflow in MSCRM 4.0 and I think the "Increment by" ability is one of those little known capabilities that can add a lot of value. One of my coworkers recently used the "Increment by" to update the number of devices an Account owned when an Opportunity was "Won." If the Opportunity that was won was for 4 devices then the Account "Total # of Devices" would increment by 4. This can be useful for Cases, Products, number of days open type calculation, etc. You can increment, decrement, multiply by or just set a field vaule all off of either a static value or a dynamic value from a field on a related form.

Great functionality that I don't see people using all that often. Hopefully this will be of use to someone out there.
David Fronk
Dynamic Methods Inc.

Friday, September 19, 2008

Mail Merge in CRM Online

This post comes from one of my co-workers who has been doing some extensive work with CRM Online. This was spurred by some data connection errors that we saw both from CRM Online as well as a couple of On Premise installations. The error only occurs through the web client, from what I am told, but basically the data connection stored in Word to pull all of the CRM data gets corrupted upon creation and isn't usable...making your CRM Mail Merge pretty lame. This is a work around for this issue. Microsoft is aware of the issue and is working on a hotfix.

Setting up Mail Merge in CRM Online. Here are some errors I got while setting up Mail Merge Documents in CRM Online, and what I did to fix it.

First I have to start with a blank Document. I choose my data fields and click ok. Here is the message I get.

"Opening the document will run the following SQK Command:
Data from your database will be placed in the document. Do you want to continue?"

I click Yes and then get this message:

From here, If I choose to "Find Data Source", I get stuck in an endless loop and can’t do anything. If I choose “Options”, then I can remove the data/header source.

Sorry for the small image, but the two buttons are "Remove Data/Header Source" or "Remove All Merge Info".

Then its regular mail merge. If I am using the web client, I have to go to Add-Ins, and click ‘CRM’. If I’m using the Outlook client, it opens the mail merge.

Once I create my xml template and upload it into CRM, I don’t have this problem with the data source anymore. I only have this problem when using a CRM Out of the Box template of doing a mail merge to a blank document.

Also, Outlook users don’t have to click Add-Ons> CRM one inside of word either, only web-users have to do that.

That should get you going and give your users some options if you ever run into this issue.

David Fronk and Team
Dynamic Methods Inc.

Friday, September 12, 2008

Managing Custom pages in IIS

I have recently been introduced to some new ways to manage custom webpages that I had no idea was readily available to me. I assume that everyone has seen those w3wp.exe processes in Task Manager, I knew that they were called Worker Processes but I didn’t realize that every Application Pool in IIS generates its own Worker Process (a w3wp.exe process in Task Manager). That being said simply by giving each page (CRM and custom pages) their own AppPool you can see any potential memory problem s, or where the largest load to IIS is among your pages. Secondly there are options on the AppPool that you can change to help as well. Here are some screenshots:

So, something like shutting down our Worker Processes on custom pages that are used as buttons after being idle for 5 minutes instead of 20 could make a big difference in a system that is already strapped for memory. Scheduling a recycle of a specific page (doing an IISRESET for just that one page) could also make a big difference. Some pretty cool features that make managing memory on our webpages that I had no idea were available to us. This may be something to put in your back pocket for a rainy day but hopefully this comes in handy for someone else later on.

David Fronk
Dynamic Methods Inc.

Friday, September 05, 2008

Methods for mass updating records in MSCRM

Working with MSCRM and from my background I have typically always been a web programmer as have my colleagues. This is essential in the MSCRM world if you want to be able to customize anything from form scripts to placing your own page that does crazy things right into the middle of the MSCRM GUI.

However, when presented with the task of needing to mass update data I have found that there are sometimes better ways than a web page. I have had minimal experience with application programming and programming an executable used to be a mystery to me.

A need presented itself for one of my clients where a procedure was needed to be rerun on a scheduled basis. Most of my previous procedures of this type were custom web pages with a "Go" button that ran all of my code. I quickly realized that I couldn't schedule a pressing of my "Go" button and I needed another solution. An executable was the solution.

I was scared that I was going to have to spend the better part of a week fighting and learning new calls and commands but amazingly enough, the majority of my code (the calls to the MSCRM API's) was all the same. For me, the learning curve into non-web programming came relatively quickly and there were a lot of benefits. There are benefits to both worlds so don't think that I've gone away from mass updating via web pages because that's not the case. Here are some pro's and con's that I have run into when developing a solution for a web based or console based solution.

Web Based Solution
Pro's: If you are already a web developer then you have all the skills required. Web pages can also be used externally very easily where console applications are a bit more difficult. One other advantage to web pages is that they are great to if you want your end users to access them and use them. Things like, update addresses for contacts related to a given account, or moving records from a sales rep's territory to a new territory owner are great for end user usage.
Con's: You have to set up the web page. If you don't build security around it everyone can see it and possibly use it. It cannot be scheduled, it must be run manually.

Console Based Solution
Pro's: Other than the coding, there is no additional set up, you just double click the executable or run it from a command prompt and away it goes. You can set up Scheduled Tasks that can run your code whenever you tell it to be run. Nightly, hourly, weekly, yearly, whatever. Also, if you build your code dynamically enough you can take your code from one installation to another and have it run just the same (authentication would have to be set up to be entered when run). Your code is compiled and no one can read your code unless you give it to them. Web pages have the ability to "View Source" and that might show off more than you want people to see.
Con's: Running externally requires that credentials be hard coded into your code. Most end users don't like running executables because they think it will install something on their machine and they don't understand what the code is doing. Black console screens (where you type in commands) scare end users. They have this mental block where if it's not in a GUI they don't understand it and would prefer not to have anything to do with it so that they don't break the system or their computer.

Well there you have it. Decide for yourself, each implementation is different so each usage can be very specific. I have a consultant's point of view where I have to be ready to do something for one client and then turn around and do something extremely similar but with minor differences for someone else and these differences between web based and console based applications can make all the difference.

Happy coding!

David Fronk
Dynamic Methods Inc.