by Gustaf Westerlund | Sep 15, 2008
When attempting to execute some of the more common tasks of everyday work as a salesperson, my colleague Joakim Westergren and I found that there actually isn’t a way of marking an appointment as complete from the normal appointment window in Outlook (like for instance a Task). If any of you reading this, know of a way, please let me know.
We did find a workaround however. We told the salespeople that when an appointment was to completed, to just add the words “DONE” or some other special character like “§” after the normal text in the description field. A workflow had been created that is triggered on changes to the description field and it checks to see if the text inside the field ends with “DONE” or the designated character. If so, the status of the appointment is changed to “Completed”.
I realise that this isn’t a perfect solution, a button would be suitable and less prone to error, but at least it is one way of handling it. I would be very intrested in any other solutions that you might have experience of, please leave a comment if you have any suggestions.
(Of course you can always open the CRM window and click “Save as completed” but that introduces a new GUI and complicates things for the users, we are looking for a simpler approach, just using Outlook)
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica Sweden
www.logica.com
by Gustaf Westerlund | Sep 15, 2008
I am currently working in the early development or late design phases of a project and a few days back, I and my colleague Joakim Westergren were going through the normal sales process and started wondering if there wasn’t an easy way of creating a phonecall activity from Outlook, with the same GUI that you create for instance emails or appointments (by pressing the “Set regarding”-button). After a while, we found it but it wasn’t obvious so I thought you’d might like to know.
You actually create a new Task and then press the lower part of the “Track in CRM” button and select “Phone Call”. The Task is now saved in CRM as a phonecall. Of course you also have to set the “Set Regarding”.
Gustaf Westerlund
Microsoft Dynamics CRM Architect
Logica Sweden
www.logica.com
by Gustaf Westerlund | Jan 25, 2008
As you are probably aware, Microsoft CRM 3 and 4 uses SQL Reporting Services for creating reports. If you are familiar with this tool from non-MS CRM implementations, there are a few tricks for getting the reports to work correctly. Please read the CRM SDK and the report writers guide for specific details on parameter naming and some other stuff.
The part that is the major deviation from normal SQL RS work, is how to deploy reports. Even though normal deployment might seem to work, the report won’t be recognized by CRM properly.
So, what do you need to do?
1. Create a report that does NOT use a Shared Datasource. Instead create an embedded datasource called CRM that connects to the CRM database server. If you are going to use the Filtered Views, you have to use Windows Authentication. Save and build the new report (DO NOT deploy to the server).
2. Open CRM, Go to “Workplace” and select “Reports”. Click “New” in the list. You will see a form where you can select the rdl-file and also select where in CRM the report will be available. Select the rdl-file that resides in the VS Project folder. Press Save.
If, at this point, you had used a Shared Data Source, you would be getting a very complicated error, as described by Menno here: http://blogs.msdn.com/mscrmfreak/archive/2006/04/27/584595.aspx
If all went well, the report will be uploaded correctly.
When uploading the report, CRM will replace the datasource in the rdl with the standard shared datasource. So, your report will still be movable.
Also, when uploading reports like this, CRM will hide all parameters starting with “CRM_”. There are several parameters that CRM will fill with data for you if they exisit. For instance the parameter “CRM_URL” will be set to “http:///CRMReports/viewer/drillopen.aspx”. This enables the report to create drill-down functionality that loops back into CRM (since there is very good support for URL-addressability in CRM).
Please note that all deployment of reports to CRM should be done in this manner and never directly from Report Designer. This is a bit of a hazzle since it is a bit tedious compared to just deploying from the Report Designer.
In CRM 4 there is a very nice wizard in the application for generating reports, even though it is not nearly as advanced as the report designer.
Gustaf Westerlund
Microsoft Dynamics CRM Consultant
WM-Data/Logica CMG
www.logicacmg.com
by Gustaf Westerlund | Jan 24, 2008
As I have been writing, I am currently involved in a rather large integration project. For those of you who don’t have experience of working with larger integration projects I would like to just share my view of how to set up the architecture connecting Microsoft Dynamcis CRM with the integration engine (BizTalk, WebSphere, Sonic and more). Bellow, I will refer to the Integration Engine, simply as “the Bus”
First of all, communication with the bus can be divided into two different classes:
- CRM Initiated Communication
- Bus initiated communication
In the picture to the right, these two are represented with a connection each (connection 1 = CRM Initiated Communication, connection 2 = bus initiated communication)
CRM initiated communication might be considered the simplest, since it mainly controlled from CRM. It can be code that runs from aspx-pages, callouts/plug-ins or workflow addons. It simply consumes the webservice at the CRM adapter on the bus.
Bus initiated communication is set up by the bus consuming a customly created web service. This “proxy” webservice translates from integrationmessages and datastructures to CRM native communication.
Integration is then definied by defining messages that uses either connection 1 or 2. Each message has two parts, Request and Response, and the response is the syncronous answer to the request. Assyncronous messages should be set up as two individual messages one for each adapter.
So, why create a proxy web service? Why cannot the bus connect directly to the CRM web service? The reason for this is usually that the communication is defined using messages (as described above) and the person responsible for the CRM Adapter on the bus cannot be expected to have any CRM knowledge in general or specificly CRM Webservice knowledge, hence that is the CRM developers job.
These are some of my experiences and reflections on integration with a centralized integration architecture. If you have any comments or you have some other method that you use, please leave a comment, so that we can discuss it further.
Gustaf Westerlund
Microsoft Dynamics CRM Consultant
WM-Data/Logica CMG
www.logicacmg.com
by Gustaf Westerlund | Dec 7, 2007
I have been developing a front-end user GUI for a product configurator as a normal aspx-page. I started the development localy and then moved the project to our development server in a virtual directory bellow the CRM directory. (Please read earlier posts concerning problems with this and how to handle it) This is an unsupported way of placing your custom aspx-pages, but the disadvantages of doing it any other way are to great.
Well, my code used ViewState to store some data between requests and this had worked fine on my local machine. But, when I moved it to the virtual directory bellow the CRM site, the ViewState handling stopped. I tried to override the LoadViewState-method but it was never fired. I tried to explicitly set the page to have the property EnableViewState = true, but that didn’t help either.
Then I remembered some things about how settings are inherited from the master website to all virtual directories bellow (i.e. the web.config settings are inherited). This is the reason for why you have to add some <remove assembly=”…”>tags to the virtual directory’s web.config when deploying bellow the CRM website.
I thought that there might be some swith in the CRM web.config that disabled the ViewState and there was; the tag I found was the following:
<pages buffer=”true” enablesessionstate=”false” enableviewstate=”false” validaterequest=”false”>
So, I copied the entire tag to the web.config in the virtual directory, changed enableviewstate=”true” and magic, it worked!
So, specific advice: This is why viewstate might not be working in a Virtual Directory bellow the CRM site.
General advice: All settings in a websites web.config are automatically inherited to all virtual directories bellow. If you want to change anything, set this explictly in a local copy of web.config.
Over and out.
Gustaf Westerlund
Microsoft Dynamics CRM Consultant
WM-Data/Logica CMG
www.logicacmg.com
Recent Comments