Managing Sales Documents in MS-CRM

One of the most common questions we get from users is how to store sales and service documents in Microsoft Dynamics CRM. These documents could be sales related like quotes, work orders, purchase requests, proposals, etc or service related like field service reports, error logs, or other documentation related to a case.

The answer to the questions, of course, is the often missed upload attachment feature .
Unfortunately this feature does not work for most Microsoft Dynamics CRM document storage needs, for the following reasons.

1. There is no version control or document management features.
2. There is no ability to search the text of documents that are stored
3. The documents uploaded are stored in the notes section and not visible when browsing the record and it is often not intuitive to look in the notes section for documents.
4. The attach document icon (the paperclip) is placed in the form header, not where people think to look to upload documents.
   

Further storing documents in MS-CRM will bloat the Microsoft Dynamics CRM database causing serious performance problems.

A better solution is to leverage Microsoft SharePoint for document management within Dynamics CRM. In this way, you get all of the document management features of SharePoint without leaving CRM. Statera offers Stratus, a web based MS-CRM and Sharepoint integration platform to do this for you.


Stratus takes a few minutes to setup and is currently available for free from stratus.statera.com.

Simple Integration of MS-CRM and SharePoint

Statera just released an easy to use enterprise application mashup called Stratus to simplify the integration of MS-CRM and SharePoint. Stratus can be setup in a few minutes and will allow you to leverage SharePoint's document management features within Microsoft Dynamics CRM (both online and on premise versions).

Once activated, Stratus adds a new tab to Accounts, Opportunities and Cases that will allow you to create Sharepoint sites and add/view documents to and from those sites.

In addition Stratus gives you visibility to key CRM information directly from within Sharepoint.

To learn more about Statera's MS-CRM and SharePoint Integration tool, go to stratus.statera.com.

CRM 4.0 issue with tracking emails

Issue: Emails are getting tracked to CRM records automatically and are not always accurate.

Cause: SmartTracking is setting the regarding on emails since Tracking Tokens have been disabled

Microsoft’s Suggested Resolution: Manually set the regarding record to the emails that were not properly tracked or turn on Tracking Tokens.

Our Temporary Solution: Our Company has tried tracking tokens before but the users didn’t like the CRM number visible in the email subject line. So turning on tracking tokens will not be our fix. So for now I have given end users instructions to manually untrack the email and then track it to the correct CRM record.

Good News: There have been rumors of the ability to turn Smart Tracking off in a future Update Rollup, and from what I have heard it may be Update Rollup 4.

Hiding Locked Fields (and hiding tabs)

It's been well posted about hiding fields and tabs using javascript:
Hiding the 2nd tab can be done with js in the onload event:
crmForm.all.tab1Tab.style.display = 'none';

Hiding a field (must know the field ID):
crmForm.all.FIELDID.style.display = 'none';

I did a bunch of this for various reasons including getting fields to conditionally appear/disappear, hiding tabs that can't be removed for some reason (but are of no use to the implementation) and so forth.

At one point I needed the "Price Per Unit" field. It's locked on the form and the only way I could see to hide it was with javascript. The field hid well, but then I couldn't remove the "$". It was an element called "priceperunit_sys". I tried lots of things, then decided to move it to a new tab and simply hide the tab.

I realized this was a MUCH BETTER solution than hiding each field individually. In this way, I now have a "Hidden" tab that holds all the fields I don't want to display to my users. The advantage is that if I (or anyone else) needs to bring the fields back, they don't need to muck around in the code. They simply move them to a visible tab.

Of course...most fields can be removed, some you may just want hidden because they're used for calculations and may never be shown, but I just stumbled across this and wanted to share.

Attribute mapping - a newbie description

I read several blogs about "attribute mapping" (see credits below). The problem is that neither gave me (as being "new" to mappings) a good understanding of what was happening. I'll try and explain a little more. This was the info I needed:

When you promote an Opportunity Product to a Quote Line Item specific field values are mapped over. But what about custom Opportunity Product fields you might have created? They don't map out of the box. You need to do something - that falls under the 1:N relationship mappings.

Account to Opportunity is one that works out of the box. If you create a custom field on Account (call it "Platform") and on every Opportunity you create from that Account you want the value of "Platform" to be populated (default) with the "Platform" field of Opportunity. You need to go to the 1:N relationship on the Account entity. The one you use has the Primary entity of Account and the Related entity of Opportunity (In this case the name is "opportunity_primary_accounts"). Then you select the Mappings link along the left nav bar. Here you can add all the custom field mappings you want.

Okay, that's long, but all well and good. Back to my Opportunity-Product to Quote Line Item mapping. On the Opportunity Product entity 1:N relationships, there IS NO MAPPINGS link. But that's what I need...well, someone smarter than I figured out how to "find it". That's what the blogs below explain.

You'll need the GUID for the relationship and once you get your URL sorted out you'll get the mappings that you didn't have.

URL: http://yourservernamehere/Tools/SystemCustomization/Relationships/Mappings/mappingList.aspx?mappingId=

Sorry if this is long winded, but I read at least 2 blogs that had this solution and I couldn't understand that it was my solution (till I tried it).


Solution blogs I used should get credit. Both blog solutions I found give the explanation of the problem and similar (or the same) solutions:
http://www.techtalkz.com/microsoft-dynamics-crm/483211-crm-4-0-opportunity-product-quote-product-attribute-mapping.html

http://blogs.inetium.com/blogs/jmiley/archive/2008/09/27/map-custom-attributes-from-opportunity-product-to-quote-product-to-order-product-and-so-on-in-microsoft-crm-4-0.aspx

Resolution to workflows not publishing

CRM 4.0 rollup 2 seems to be the cause for workflows no longer publishing. So follow these steps to resolve the issue.
Find the CRM web.config file and make a copy/backup of it.
Open the web.config file and browse to the AuthorizedTypes section
Paste in the following text:

Save and close the web.config file. That is it. Microsoft mentioned they should have a KB artical about this soon.

-Laura

How not to mess up your environments (or learn from my mistakes)

Here is a fun one:
An error has occurred. Try this action again. If the problem
continues, check the Microsoft Dynamics CRM Community for solutions or
contact your organization's Microsoft Dynamics CRM Administrator. Finally,
you can contact Microsoft Support.

Right, lots of info there. Troubleshooting? Let's not even talk about what I tried to do. What happened? Well, I broke it. Good thing this was development environment and not production. I did what everyone tells you not to do, but at least I had the forethought to "TRY" it out first.

I had been working with a development system that was quite old. No one really knew when it was set up, if it was a snapshot of production, when the last time data or configurations had been migrated...all we knew was that it wasn't 100% perfect, but it was good enough. I'd been using it for a couple of weeks, trying some configurations out, code, entities, all sorts of stuff.

Suddenly, we were given a new environment built on virtuals - "Yeah!" yelled the developers. This sounded great. It was a recent snapshot of production (minus data), but it worked (for the most part). Minor inconsistencies (that I wont elaborate on) aside, it was good.

At this point, I needed to move any new developments from the old dev system to the new one. No big deal. This would be a good test for moving changes we'd made to the production system...Here goes. First, back up the customizations from the dev virtual, then we dove in. Made a few changes, added some objects, then pulled 3 or 4 entities from the old dev and imported to the virtual.

Let's publish...and get an error. No biggie...we get those. But no solution to be found.

After searching and looking, importing backups and everything it came down to this...

Creating an object in CRM assigns a GUID that is carried over (within the database) when exporting and importing to new environments. If you create a new object in 1 enviroment that has some 1:N or N:1 or N:N relationship to another, then recreate that object in a new environment EVEN IF YOU DON'T IMPORT THAT OBJECT those N:1, 1:N, N:N relationships reference the GUID...if you import an object that is related to the one you created...you're dead in the water. You can't "un-import", even importing the backup entity doesn't fix the issue.

I may explore the configuration database and see if I can manually remove/update, but I think that will just create other issues. I can't delete those objects in my new dev and try to recreate them with an import because the relationships somehow prevent this and they (the relationships) cannot be removed.

Anyway, this has rambled on longer than I wanted to, but wanted to get this info out as I find it important to know.

Again, really good that we found this out now rather than doing it in production :)