Installation vom Microsoft Dynamics CRM 4.0 Client mit Outlook 2010 64-bit schlägt fehl

No. KBA-01032-YBRYDB Keywords: Outlook 2010 64-bit, Microsoft Dynamics CRM 4.0 Last Modified: 03.06.2010 Problem Installation vom Microsoft Dynamics CRM 4.0 Client mit Outlook 2010 64-bit schlägt fehl. Lösung Der Microsoft Dynamics CRM 4.0 Client für Outlook supported nur den 32-bit Outlook Client. In der Version 5.0 wird auch der 64-bit Outlook Client unterstützt. Es gibt…

Details

Microsoft CRM Outlook Client and Update Rollup 11 (UR11) Last week Microsoft released Update Rollup 11, which I had been patiently waiting for to see how it works with Outlook 2010. I am happy to report that it delivers the goods! I have had Microsoft Outlook 2010 installed on my laptop for a while but…

Details

Dynamics CRM 2011- Setting Multi-Level Categories Against a Record Codelessly

Nice Summary from Leon:

This is a bit of a variation on a theme I did a while ago when I talked about using filtered views for address population. In this case I wanted to explore if we could set up a subject-like hierarchy and then use filtered lookups to enter category levels easily against an account. It turns out it works quite nicely. image

Essentially, you set the first category from you list of top level categories. Then, you set level 2 which will automatically adjust to only the valid values, based on the category 1 value. Finally, you set the category 3 value, based on the value in category 2.

So How Do I Set This Up?

First of all, we create a new Category entity. image In this case I have stripped everything out; there are no notes, activities etc. and the record is organization owned. Next I set up a recursive 1:N relationship so that for a given category I can set an infinite number of category levels, each with an infinite number of categories. image The main points of interest here are the changing of the display name to ‘Parent Category’ and the changing of the display option to ‘Use Custom Label’ so I can refer to the next level down as ‘Sub Categories’. On the category form I also add the parent category lookup, created as a result of this relationship. image Finally, I add three lookups to the account form so I can add three levels of category to my account record. image Finally, I populate my category hierarchy. Unfortunately, there is no nice tree view to employ so I fill it up in pretty much the same way I would if I was populating, for example, an account hierarchy. My advice would be to do it via a data import.

Where’s The Magic?

So far this will just let us pick three category values from all category values and add them to an account; not exactly exciting. The trick comes in adjusting the filters on the lookups. For category 1, we set up a new system view called Level 1 Categories. This just shows those categories with no parent category i.e. they are at the top of the tree. image We then go to our first lookup and force it to only use this view for its values. image The result is when we click the lookup only the values in the top level appear. image For the other two lookups, we use the Related Records Filtering properties of the lookup. For the category 2 lookup, we set it as follows: image The setup for the category 3 lookup is identical, except we replace ‘Category 1 (Accounts)’ with ‘Category 2 (Accounts)’. This means, clicking on, say, the category 2 lookup shows only the valid values, based on the selection for category 1. image And that is it. With all that set up, all the user has to do is pick the category 1 value and the category 2 values will be auto-filtered. Once the category 2 value is selected, the category 3 values will filter.

Why Not Use Subjects?

Subjects are nice in that they can be linked to an account with a 1:N relationship and they have a tree view lookup. However, they do not, at this time, play nicely with lookup filters. If you add a subject lookup to an account form and try to filter its values, based on the selection in another subject lookup, CRM throws an error. This has been reported and, I am sure, will be addressed in a future roll-up.

Conclusions

If you have a multi-level hierarchy you wish to apply to a record, such as an account, and you are looking for a reasonably user-friendly way to capture the information this is not such a bad solution and does not require code or Silverlight web resources. While my first choice would be the subject entity, because of its friendly tree view, if this is not practical, this solution provides an alternative approach which supports any number of category levels.

Nice Summary from Leon: This is a bit of a variation on a theme I did a while ago when I talked about using filtered views for address population. In this case I wanted to explore if we could set up a subject-like hierarchy and then use filtered lookups to enter category levels easily against…

Details

Summary: How to change the maximum number of records that you can export from Microsoft Dynamics CRM 2011/4.0/3.0 to a Microsoft Office Excel worksheet

Change Excel Export Limit for Microsoft Dynamics CRM 2011 In Microsoft Dynamics CRM 2011 ist die Anzahl der Datensätze, die man nach Excel exportieren kann, auf 10.000 begrenzt. Es gibt keine Möglichkeit diese Grenze zu erhöhen – kein supportete Möglichkeit. Unsupportet sieht das ganze schon anders aus. Mit folgendem SQL-Statement kann man die Grenze auf…

Details

Calculate the Actual Value of an Opportunity in Microsoft Dynamics CRM 2011 Using .NET or Jscript

Calculate the Actual Value of an Opportunity in Microsoft Dynamics CRM 2011 Using .NET or Jscript This illustration shows how to calculate the actual value of an opportunity in Microsoft Dynamics CRM 2011 with CalculateActualValueOpportunityRequest. This example will be given in Jscript (SOAP) and in C# (.NET). Ok, here is what the code looks like!…

Details