Collect all CRM pitfalls here

ShenpenShenpen Member Posts: 386
edited 2005-05-11 in Dynamics CRM
Hi all,

I would like to collect all CRM pitfalls here - I mean conceptual issues, not tech problems that will hopefully corrected in hotfixes.

Do It Yourself is they key. Standard code might work - your code surely works.


  • ShenpenShenpen Member Posts: 386
    1) Outlook client - can link the Appointment, Mail etc. to only 1 thing - an Account, an Opportunity. Solution: connect it to the opportunity, or if no opportunity, then to the Account, and then design reporting to show both directly and indirectly (through an Opportunity) linked tasks to a given account.

    2) Outlook client - Opportunity to be linked to Appointment etc. can be found only by name. Solution: users must name their opportunities like "271JS Deloitte servers selling", where 271 is the code of the cost center, JS stands for John Smith, and Deloitte is the name of the Account. In Outlook, they search for 271JS and then choose the opportunity by the Account name, in this example, Deloitte.

    3) Search does not find inactive records - use Advanced Search.

    4) Outlook client - importing contacts. a) Move all Outlook contacts to another folder. b) After data migration, search for your contacts (Advanced Search - they may be inactive!). Take not of those who are not in CRM. c) Move those Outlook contacts to the original folder and do the import. Then, go into CRM and link them to Accounts.

    5) Outlook client - contact synchronization. If you import a marketing database, f.e. 50 000 company, 150 000 person, and you do not do it as suggested: Leads, because Leads have too few information, f.e. only one person, but you do it as logical: Accounts and Contacts, making inactive during the import those ones who are not active partners, then you might
    have 150 000 Outlook contacts after synchronization... because CRM synchronizes inactive contactas too. Solution: make a Marketing business unit
    and import all these inactive companies there.

    6) Outlook client: search uses SQL regexps: search %company%, not *company*. Web client uses Windows regexps, search *company*.

    7) Cannot customize Tasks views. Standard views are unusable: don't even show user and time. You must use external reporting: Crystal or SQL.

    8) Cannot send sensible e-mail notifications. F.e. a notification about "An account has been assigned to you" does not contain Account name
    or link to the record. E-mail templates do not help: they go to the Account, not the owner. Solution: .NET ASP external program with Workflow
    sending data by post method. Yeah, right. I actually want to do it with Perl CGI program, because that's 50 lines at most, .NET ASP would be much more.
    Did not try yet, hope it will succeed.

    9) Reporting. Well, Advanced search and custom views are unusable: cannot customize Tasks, which are the MOST important (after all, almost everything else is
    in your ERP software), and even if we could, we cannot make views or searches like "all opps for those partners who have sales > 10000 or like. Crystal might
    help, but have no intention of learning that, and I am sure it has limitations or bugs, because why would it be the only part of CRM that does not have? :)

    Solution: plain, good, old SQL. You need two things for SQL reporting: table relation (lookup) denormalization and picklist denormalization.
    Lookups are denormalized in standard views, and I wrote Perl script to make picklist-denormalized views (in another database of course). It is easy,
    you just take syscolumns, look up an entry in stringmap table, if you find, then you show that, if not, show original value. Easy, but thousands of lines of code,
    so I generate it automatically with Perl script. I think we will use Delphi forms to show reports - maybe we manage to hyperlink the original records too.

    10) Data migration. I did not even try CDF. Hell, have you ever seen a data migration where the source data was 100% correct? You ALWAYS need to batch modify
    data after migration, during production operation, and you cannot do it with CDF. And I did not dare to write directly to the SQL. So, we hired a .NET programmer
    to do a .NET import by SDK. It took 2 weeks, but was very good: took records from Access, tried an import for every record, if successful, wrote back the GUID to
    Access if succesful, if not successful, then wrote back the error message to Access and go to next record. And it imported only those without GUID - so you run it
    once, then look at records in access with no GUID, correct data, and rerun, and now it runs only on those records. Very good :) But it still run 3 days on 45 000 accounts,
    100 000 contacts from marketing database - SDK is very slow, about 1 record / second...

    Do It Yourself is they key. Standard code might work - your code surely works.
Sign In or Register to comment.