Topic: ‘Data’

While setting up an integration for a client, it became apparent that there is a problem with the MSGP Publisher that will only allow you to publish messages to the scribepublisherqueue for specific tables. After adding a table to the publisher and choosing options, I tried to save the publisher and it threw the error “Error when setting up GP Publisher: Sequence contains more than one matching element”. I never did figure out what that meant. After doing my diligence and checking the knowledgebase and forums on Open Mind to no avail, Scribe support was contacted for some assistance. They informed me that there is a known issue with many tables not being accounted for by the publisher and that it is a defect and there is no fix at this time. This left me with no resolution or workaround (thanks Scribe!) While Scribe gave us what they considered an acceptable answer to the problem, it didn’t solve anything for our client’s integration which left us to figure out one on our own. Here is what I came up with: Read the rest of this entry »

Creating personal Advanced Find views from within the Dynamics CRM application is a very helpful analytical tool. You can leverage preferred column headers and filter criteria, and you can access the views anytime you need to without having to recreate the criteria. Sharing is simple, allowing you to give other members of the CRM application access to the filter criteria that you’ve created. But static analysis of your CRM data can only be so beneficial – especially for those of us who rely on more visual analytics.

Now, it’s good to know that from within the 2011 version of Dynamics CRM, you have access to charting, which allows you to leverage a visual depiction of your CRM listviews. There are numerous out of the box charts that provide value, and you have the ability to create new charts if you wish to do so. There are some limitations, such as multi-series charts and scatter graphs, but the options available are very robust. Read the rest of this entry »

There is a big change in CRM 2011 that isn’t really talked about much, but it has an impact in some key areas. In CRM 4.0 there was a column in the database tables for each entity to tell you when a record was deleted or not – DeletionStateCode.* It had the following possible values: 0 meaning the record was active in the database, 2 meaning the record was marked for removal when the deletion service next runs, and 1 which was not used. On a schedule the deletion service would skim through the tables and remove all the records with a value of 2.  Fortunately or unfortunately (depending on how you look at it), the deletion service had problems and often didn’t run or would leave records in the system. When developing against the CRM environment (i.e. any custom SSRS reports, SQL queries, custom web pages, or plugins), you would need to take into account records with ‘deletionstatecode = 2’ (either excluding/including them based on what you were trying to do). There was an upside however; the inclusion/exclusion made it easy to be able to go back and look for missing records that may have been deleted accidentally and recover them or determine who had deleted them.

In CRM 2011, ‘DeletionStateCode’ no longer exists. When you delete a record, it goes bye-bye for good. There is no trace of it left behind. This means that you do not have to include it in your customizations against CRM anymore. If you want to be able to go back and retrieve old records you will need to do a restore to a backed up version of the database.  If you want to see who deleted what, you will need to use some type of audit logging.**

How does this affect your system? If you are new to Dynamics CRM 2011, it has no impact, but if you are upgrading…this means you may have some work to do. If you have customized your system beyond simple configuration and reference DeletionStateCode in your custom code, reports, or queries, you will need to go and remove those references to prevent errors from rendering your customized system useless. Additionally this is very important when planning for your upgrade from CRM 4.0 to CRM 2011. Make sure that you run the deletion service manually prior to upgrading and also check that all records with a DeletionStateCode = 2 that the service might have missed get removed from the system as well. If there are any records remaining in the database when the system gets upgraded, they will magically reappear as active records when you log into CRM 2011! While it might be a little tedious, it is not a difficult change process if you know ahead of time what to expect.

*Microsoft will tell you that it was unsupported to reference the DeletionStateCode if you ask them to assist in fixing any problems you may encounter in regards to this field. Catch 22 – you had to reference it while customizing 4.0 because the deletion service never worked and your data would be incorrect. Good news is, you don’t need to worry about it anymore because they removed the process - but your upgraded customizations will have to be modified.

**CRM 2011 has auditing functionality built in natively.

Understanding how to pull various CRM data into your Outlook for CRM 2011 Client from your CRM application is very helpful. Understanding how to do it outside of the defaults is even better.

This recent post on the Microsoft Dynamics CRM Team Blog sheds some light on how to modify what are called Local Data Groups. These settings determine what data is pulled into your Outlook application from CRM. Read the post by clicking here.

The concept of merging inside of CRM is immensely helpful, especially if you are taking data from multiple databases and placing them inside of one database, like Dynamics CRM. Merging allows you to select two records that are duplicates, transfer data from one to the other, and deactivate the secondary record.

While this is helpful, it can also be dangerous – no data will be truly lost, but it will no longer be searchable on the primary record, and it will be tedious and difficult to transfer. Also, without correct planning, you may end up doing more warranty work than you originally signed up for. Read the rest of this entry »

There are several different ways to create records inside of CRM – well, as you use the CRM application, you’ll find there are several different ways to do just about everything, which can be a bit overwhelming. Fear not – there is always a BEST way to do each (at least in my opinion).

In this specific article, I’ll chat a bit about the creation of new child records – for example, a new Contact record, or even a new Activity record. For some, the creation of a new record is easily done by using the Dynamics CRM toolbar in 4.0, located at the top of your interface below the Microsoft Dynamics CRM logo. Another location is on each of the listviews, located throughout the CRM application. HOWEVER – if the record you are creating is a CHILD record of another record currently inside of the system, there is a better way.

Best practices encourages the use of what’s called data mapping, the transfer of data from one record – i.e. a parent record – to another record – i.e. a child record. A great example of this would be the transfer of information from an Account to a new Contact. There’s never really a need to retype all the information that should transfer over.

To utilize data mapping and follow best practices, the correct location to navigate to in order to create a child record is the ASSOCIATED VIEW of the child records, located underneath the parent record. For example, the Associated View of the Account’s Contact records would be inside of the Account form. Once you click on Contacts on the left-hand side of the Account form, you will now be viewing the Contact’s Associated View underneath the Account. The Activities section would be the Activity Associated View underneath the Account, and so on and so on.

Click on the New button from inside of the Associated View. Once the window opens, you will see the data transfer. Now just to be clear, this is all contingent on whether or not the information is actually FILLED OUT at the Account level. As long as that information is filled out and SAVED on the form, the information will transfer based upon the mapping configurations.

Some companies may request a dual column sort based upon two separate fields. This kind of “custom” sorting is actually standard in the CRM application. By holding down the Shift key and selecting multiple columns, you can sort by more than one option.

One of the more common requests is a Priority and Date sort.  The goal in this situation is to create a “single sortable key” that is based on a numeric value – Priority - and date value – Created By.  To accomplish this task, you will need to create a new field to the store the concatenated value. Then add the jscript below to two separate locations inside of the entity’s configuration area: firstly in the OnChange event for Priority and Date fields and secondly in the form’s OnLoad event. 

The following script will concatenate a numeric field (new_callpriority) with a date field (Created By) and then format the date adding “-“in place of “/”.  Read the rest of this entry »

During my time as a CRM Consultant, I’ve realized something very important. However troublesome the journey, there’s always a silver lining – experience. So even though I’ve only been in the game a short amount of time, I’ve come up with a few best practices that I prefer to follow when implementing Dynamics CRM. For those who know me, I tend to be…opinionated is a good way to put it. So, yes there may be other ways to utilize CRM and still get by.

It’s known that each process flow – sales, marketing, service, SOP – requires a different path, but these should provide you with broad and useful guidance inside of CRM. Do note that the list below is by all means incomplete (Oh yes, I have plenty more…). These statements are an example of the tips that have given my clients – regardless of industry and business practice – the ability to enjoy clean, useful, and more importantly, valuable, CRM systems.

• For DATA ENTRY…Before importing data into the CRM system, spending a little bit of time running through and shaping the spreadsheet. Cleaning up the rows and columns will save you hours of data cleansing down the road. CRM is only as good as the data that is placed into it. And who knows – you may have missed a column that you need inside of the system.
• For PROJECT MANAGEMENT…Document, document, document. There is no such thing as “documenting too much.” Clients love nothing more than to see a clean, printed, color document with their logo on the front (who doesn’t?) and all the CRM information they could need. Documenting too little, however? That (unfortunately) exists.
• For PROCESS FLOW…When converting to Customer records (in the situation where the Customer does NOT exist in the system yet), I always recommend converting to at least an Account and a Contact. This is not only a time saver, but it is proper structure. After speaking with and qualifying a Lead, you are always going to have a company and a person in the system (Who signed the Contract? What organization did you type into Hoover’s before meeting with them to do a demo?). The one exception may be the Opportunity. If there’s no potential revenue to begin working within the next 6 months (depending on your average sales pipeline time and size), you can probably hold off on the Opportunity until you see it in the pipeline and can properly document what is necessary.
• For ATTRIBUTE ADJUSTMENT…When renaming fields, rename from the Attribute level the majority of the time. The main time renaming from the Form level comes in handy is when you have more than one field that needs to be named the same. (Example, “Date”). You can rename them in a unique manner on the Attribute level, and make them uniform on the Form level. The reason for this is mainly due to Advanced Find search capabilities. If you name everything the same, you will have more than one field in the AF search on that particular entity (causes much confusion).
• When CREATING FIELDS…When creating a new field, once you save the record after creation, you CANNOT change the type. So always be sure that you have the correct field type selected, otherwise you will have to create another field. So after I create a Picklist, I cannot “change” it to a character field. Same thing with the schema name – once the field is created, the schema information set in stone. To “change” the field, you would only be able to create a new field and remove the old one. I always document exactly what I need to create BEFORE creating them in the system. If you’re working for a client, create a spreadsheet of the fields (Display Name, Field Type, Requirement Level, Number of Characters (for Nvarchar fields), Potential Values (for Picklist or Bit fields), and any additional information) – this is important for proper generation and understanding. Nothing’s worse than realizing you’ve made a dumb mistake and having to delete and recreate 100 fields. And then justifying (or more accurately, trying to justify) the additional work to the client…
• For WORKFLOW…Always map and plan your workflow first before building the structure: this will help you just in case you make a mistake in the structure. Plus, mapping it out allows you to understand exactly what needs to happen. You may need a wait condition instead of a check condition – you can’t change this after you build the workflow.
• For WORKFLOW…You can’t change conditions in the logic, so always make sure that you’re creating the workflow properly from top to bottom. This statement certainly ties in with the workflow best practice listed above. When adjusting the structure of a workflow, if you are removing/adjusting part of the basic structure, deleting one step will remove everything after it.
• For ADMINISTRATION & TROUBLESHOOTING…Never delete a used security role. I know, you have the ability to do it, but I wouldn’t. Especially if a CRM user (or more than one CRM user) currently has the role. Deleting a utilized security role will kick those respective users out of the system. If you do want to get it out of the system, do this. Copy the role and plan on using the new role. Rename the old one to say “UNUSED” or “OLD.” Spend some time making sure all of the users are not assigned that particular security role. Run reports, AF views, whatever will help you verify that no one currently has that particular role. Then remove it from the system. This will keep you from getting dozens of angry, frantic emails.
• A CRM/OUTLOOK TIME SAVER…Utilize CRM shortcuts from inside of an email. After you track an email or Contact from Outlook inside of CRM, there are two buttons inside of the individual Outlook record that will take you directly to the respective records inside of CRM: View Record and View Parent (this will take you to the actual CRM record). This is really handy if you’re converting an email to an Opportunity.

Do you have any tips or tricks that you use when implementing CRM? If you do, I’d love to hear them!

Use the Microsoft Dynamics® CRM Adapter for Microsoft Dynamics GP to integrate Microsoft Dynamics CRM and Microsoft Dynamics GP data. For example, you can integrate Microsoft Dynamics GP customers with Microsoft Dynamics CRM contacts giving you access to up-to-date customer/contact information in both systems.

The Microsoft Dynamics CRM Adapter for Microsoft Dynamics GP is intended to be used in an implementation where Microsoft Dynamics CRM is used to manage business contacts, track leads, enter sales orders, and perform other sales and marketing activities. And where Microsoft Dynamics GP is used to perform accounting functions, manage your company’s chart of accounts, and maintain customer, vendor, item, employee, and other records.

Within the Microsoft Dynamics CRM Adapter for Microsoft Dynamics GP, separate adapters are used to identify a source system (where data is read from) and a destination system (where data is written to). The source adapter reads data from the source system. The destination adapter writes the data to the destination system.

Record types that are integrated are referred to as “entities.” Some entity information can be integrated only one way between the two systems. For example, a Product that is entered into Microsoft Dynamics CRM cannot be integrated with Microsoft Dynamics GP as a Sales Item, but a Sales Item that is entered into Microsoft Dynamics GP can be integrated with Microsoft Dynamics CRM as a Product.

You can use this product to integrate the following entities in Microsoft Dynamics GP and Microsoft Dynamics CRM.

Adapters

Adapters are used to connect the runtime to the Microsoft Dynamics CRM and Microsoft Dynamics GP Web Services. This connection is used for reading and writing data from one application to another application.

The following adapters are provided:

• Microsoft Dynamics CRM 4.0 adapter
• Microsoft Dynamics GP 10 adapter
• Microsoft Dynamics GP 2010 adapter

Transformation engine

At its core, the Microsoft Dynamics CRM Adapter for Microsoft Dynamics GP moves data from one system in one format to another system, in a different format. The adapters provide or supply the data from the source and destination systems, and the transformation engine changes the data from one format to another. The change that is made by the transformation engine is determined by the map that is associated with the type of data that is being moved. For example, to move a Microsoft Dynamics GP customer record to a Microsoft Dynamics CRM account record, the transformation engine creates a Microsoft Dynamics CRM Account object based on the transformation that is defined in the CustomerToAccount.map file for the Microsoft Dynamics GP customer entity and sends it to the Microsoft Dynamics CRM system using the Microsoft Dynamics CRM Adapter.

 Map templates

The Microsoft Dynamics CRM Adapter for Microsoft Dynamics GP includes a series of map templates that provide default field mapping between source and destination entities. You can create and edit new maps from the templates. You may need to do this to meet specific business needs or to ensure that any customizations that you may have made to your source or destination systems are considered. Map template files are stored at the installation location in the Templates folder and have a .map file

 Availability

This adaptor is only available thru your partner and is available at no charge. Installation and implementation can be quoted base on specific requirements where applicable.

There’s an interesting post on the MSCRM Team Blog by Inna Agranov that verbalizes how to pre-filter your data in CRM, allowing you to query results much quicker. The post also contains a link to another article, located in the MSDN library. It describes in more detail how to filter CRM reports through SQL Reporting Services.

Click here to go to the Team Blog and read the post, or click here to go directly to the MSDN article.