Friday, September 26, 2008
Friday, September 19, 2008
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
Dynamic Methods Inc.
Friday, September 05, 2008
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.
Dynamic Methods Inc.