Topic: ‘Customization’

Field-Level Security in Microsoft Dynamics CRM 2011

Have you come across a requirement where you have to ensure  certain fields are visible to only certain users or team members and/or  updatable by certain users or team members?

It could have been a Privacy Requirement where the Contact Information for the customer data such as their home phone, address etc. should not be visible to anyone else except the employees who have signed some legal  document not to disclose it or use it for only for pre-determined reasons. It could have been a requirement where a Customer hot line should be visible to only the “Account/Sales Managers”. 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.

The way the 1:N parental relationships work inside of Dynamics CRM is based upon what’s called “Cascading” Relationship Behavior. For example, when an Account is assigned to a new Owner, by default all child records (including Contacts, Activities, and Opportunities) assign over to the new Owner.

Sometimes this works fine – but there’s definitely a caveat. Let’s say there’s a collection of historical data that has been deactivated inside of the CRM system, or even more importantly, CLOSED. This applies to Opportunity records. Because the Assign and Reparent settings are set to “Cascade All,” any child records of their respective parent in the system, regardless of status, will be reassigned if the parent is reassigned.

In my mind, this creates issues – especially if you have assignment notification worlflows running in the background. Let’s continue with the Account reassignment example, in the case where the Opportunities would be reassigned as well. There are two options here:

OPTION 1 – CASCADE ACTIVE: The cascade setting that most companies would want would be “Cascade Active.” This would only reassign Active (Open) Opportunities to the new Owner, and leave the closed ones alone. This is very helpful for companies where Accounts get reassigned often AND for companies that use Opportunities.

To change to “Cascade Active”:

1. Change Type of Behavior to “Configurable Cascading.”
2. Change Assign to “Cascade Active.”
3. Change Reparent to “Cascade Active.”
4. Publish your changes.

OPTION 1 – CASCADE NONE: If you do not want any Opportunities to be reassigned based upon Ownership change at the Account level, you would need to change it to “Cascade None.” This is more helpful for companies where the Ownership of the Account is not significant, and sales reps would not transfer Opportunities in the case of an Ownership reassignment at the Account level. NOTE in this case, you would need to reassign Opportunity records manually if someone leaves the company, for example. This can be done in bulk through Advanced Find.

To change to “Cascade None”:

1. Change Type of Behavior to “Configurable Cascading.”
2. Change Assign to “Cascade None.”
3. Change Reparent to “Cascade None.”
4. Publish your changes.

NOTE: If you create Opportunities off of the Contact record, you will need to make any modifications from the CONTACT to Opportunity Parental Relationship page, not the Account to Opportunity relationship.

Additionally, you have these cascading options with Share and Unshare (you cannot make these changes for Delete and Merge). I would analyze the common actions made within your company to see if these relationship behaviors need to be altered as well.

I think analyzing these relationship behaviors will be beneficial to almost any company. It will save you from the inevitable “I’m getting a new Opportunity for WHAT now?” conversations with sales reps across the entire company.

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.

Inside of Dynamics CRM, there is a specific location where you need to go in order to modify what information transfers over from a parent record to a child record upon creation of the child record (for example, creation of a Contact off of an Account).

To continue with the above example, follow the steps below to modify the mapping behavior in the Account to Contact relationship:

• Go to the Account customization page (Settings, Customization, Customize Entities, Account).
• Go to the Account to Contact parental relationship. TIP: It’s helpful to sort inside of the relationship are by Related Entity – then look for Contact (1:N Relationships, account_contacts).
• Go to the Mapping section of the relationship page (Mappings).

This page displays all of the EXISTING mapping behavior that is currently specified. There really is no “Edit Existing,” so you will need to create a new mapping record. (NOTE: If one already exists that is PUTTING INFORMATION INTO the field that you want to use on the Contact side – i.e. the Target – you will need to DELETE the existing mapping and create a new one. You cannot create more than one mapping that is putting information into the same field).

• Click New.
• Choose the SOURCE field and the TARGET field. TIP: It’s handy to sort by Display Name – I find it easier to find information that way. You will single highlight the SOURCE on the left side of the screen, and you will single highlight the TARGET on the right side of the screen.
• Click OK to solidify your mapping selection.
• Save and Close out of the Relationship window.
• Publish your changes.

Once you’ve finished with the changes AND properly published them, test out your new mapping selections. Create a Contact from an Associated View of an existing Account (make sure the fields you’re mapping HAVE DATA IN THEM before testing – otherwise, there will be nothing to transfer),  and make sure everything transfers correctly.

A new whitepaper has surfaced in the community from CRM MVP Julie Yack and David Yack. The whitepaper will gear towards CRM developers and ISVs who are looking for information on how to utilize their skills in the new CRM2011 platform.

You can access the whitepaper from Jim Glass’s blog post here.

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!

Nothing good, that’s for sure. You probably won’t know until you encounter a similar problem, but there is actually hidden javascript code on the form that invokes actions when this field is selected. When you remove the field from the form, so goes the code. If you decide to put it back on the form, the code doesn’t come back with it. The main result of this is that when you try to select a Default Price List using this lookup, nothing is returned in the lookup list, even if you have values. Therefore, you cannot add Products to Opportunities.

To get the code back on the form, perform the following:

1)      Export the customization xml of the entity in question after you have added the Default Price List back to the form.

2)      Open the xml in a text editor.

3)      Search for the text “Price List”.

4)      Between the </labels> and <control tags for this field, paste the following text:

<events>
<event application=”true” active=”true”>
<script>
<![CDATA[
var oLookup = event.srcElement;
AddTransactionCurrencyParam(oLookup);]]>
</script>
<dependencies>
<dependency />
</dependencies>
</event>
</events>

5)      Save the xml and import back into CRM.

Everyone loves customization – especially CRM clients. Having the ability to view and use a record customized to your day-to-day business process flows is extremely valuable. Donna Edwards has posted a great blog example on the Microsoft Dynamics CRM Team Blog regarding the creation of a custom Quote, Order, or Invoice record by utilizing Visual Studios 2005 (she has mentioned in the blog post that the same principles apply when using 2008). Click here to view the post.