Tip #201: Mobile App New Features Spring ’14

If you are still trying to figure out all the new features in the Spring ’14 release to Microsoft Dynamics CRM Online, join the crowd. It’s the old, drink from the fire hose challenge. So over the next 5 days I am going to post by topic links to new feature videos that the CRM product team put together. Most of them are real short – 5 minutes or so, but none of this 1 hour stuff.

Here is the challenge, each day this week open up the next tip in the series and while you are eating lunch at your desk or taking a breather between tasks, play a video.

Today’s videos are all on Mobile

Overview

YouTube player

New Features

YouTube player

Windows 8 App

YouTube player

Android App

YouTube player

Tip #200: Now you see it now you don’t

As you may or may not know, Unified Service Desk (USD) has made its appearance alongside with CRM 2013 SP1 in May 2014. It makes use of User Interface Integration (UII) SDK capabilities that has been part of Dynamics CRM SDK download since December 2013. We thought it was important back then but now there are other reasons to be excited about it.

USD makes use of UII capabilities and is delivered within CRM overall framework but to make it work, the team had to add some features that’s been on our wishlist for a long time. One of these features is ability to hide navigation elements of the URL addressable forms, views, dialogs and reports.

The following are the query string parameters used with the main.aspx page to open entity forms or views:
…

navbar

…Controls whether the navigation bar is displayed and whether application navigation is available using the areas and subareas defined in the sitemap.

  • on — The navigation bar is displayed. This is the default behavior if the navbar parameter is not used.
  • off — The navigation bar is not displayed. People can navigate using other user interface elements or the back and forward buttons.
  • entity — On an entity form, only the navigation options for related entities are available. After navigating to a related entity, a back button is displayed in the navigation bar to allow returning to the original record.

cmdbar

…Controls whether the command bar is displayed.

  • true — The command bar is displayed. This is the default.
  • false — The command bar is hidden.

For example, try dropping the following into your browser and you should see Active Contacts view in a naked browser:

https://<your CRM URL>/main.aspx?etn=contact&pagetype=entitylist&viewid={00000000-0000-0000-00AA-000010001004}&viewtype=1039&navbar=off&cmdbar=false

What’s great about it is that now you can embed CRM views and forms into other web pages in iframes and drop them into portals or SharePoint. And if you have single sign-on sorted out, users won’t even know that it came from CRM.

This tip was a timely reminder from Mark “Sweet nzCRMguy As” Smith

Tip #199: Form customizing ninja

True ninja knows Himitsu iri or the art of “Silent movement”. Ability to move quickly and without screeching mouse noise is crucial when it comes to quickly whipping a prototype or putting out fire in production. Minimizing mouse movements is important skill that keeps your boss, your customers and your wrist happy. These are just some of the shortcut techniques that true customizer needs to know when facing a very visual but often daunting form customization dialog.

Alt-Space Brings up Properties dialog of the selected tab, section or field in focus
Ctrl-[ Switches focus to the ribbon’s tabs
Ctrl-] Switches focus to the ribbon
Ctrl-Space Scroll down
Shift-Space Scroll up
Del Removes element in focus (doh!)
Ctrl-Z Undo (phew! keep pressing)
Ctrl-Y Redo (doh!)
Ctrl-S Save

Though the following is actually a mouse shortcut, it deserves the mentioning because you perform it with your fingers not the wrist

Double‑click Changes editor focus to the area of double-click. For example, if you are editing form’s body, simply doube-click on the header to start adding/removing fields in the header. Works for body, header, footer and navigation area.

Have your own favorite shortuct for form customization? Send it to jar@crmtipoftheday.com!

Tip #198: Understanding Upgrade Options

I recently had the opportunity to collaborate with some of my MVP friends on a new book called CRM 2013 Quickstart. This book is a follow up to the CRM Field Guide and is designed for someone who is familiar with earlier versions of Microsoft Dynamics CRM and wants to get familiar with the new features of CRM 2013. See the table of contents here.

You can buy the book at http://www.crm2013quickstart.com. Enter code JoelLindstromQuickStartBook for a discount at purchase.

The following is an excerpt from chapter 8 — upgrading to CRM 2013.

———————————————————————————————————————————————————

If you use Microsoft Dynamics CRM 2011 On Premise, you choose when you upgrade, and the upgrade methodology that you will use. There are three different options that you can choose:

In-place Upgrade

In this option you will install CRM 2013 on an existing CRM 2011 server. During the installation, your CRM environment and database will be upgraded to Microsoft Dynamics CRM 2013.

Benefits of in-place upgrade

  • Re-use existing CRM server architecture and SQL Server
  • Preserve the existing URL and IP address for CRM
  • Outlook clients do not need to be reconfigured.

Risks of in place upgrade

  • Destroys CRM 2011 environment during installation
  • No roll-back option
  • Cannot be tried effectively prior to upgrade
  • May leave artifacts of CRM 2011 application on the CRM servers

Point to existing database upgrade.

In this option you will install CRM 2013 on a new CRM Application server, but you point it to the existing CRM SQL Server. A clean copy of the application is installed, and during the installation the MSCRM SQL database will be upgraded to CRM 2013.

Benefits of “point to existing database” upgrade

  • Re-uses SQL Server
  • Fresh application server with no artifacts from previous version
  • Can be rolled back by restoring a backup of MSCRM_Config and *_MSCRM databases

Risks of “point to existing database” upgrade

  • While this option is less risky that an in-place upgrade, it still destroys the CRM 2011 environment during the installation, requiring more user down-time than an import upgrade.
  • Given that the installation upgrades the CRM 2011 database during installation, this option cannot be effectively tried multiple times prior to upgrading.
  • Since CRM 2013 is installed on a different application server than CRM 2011, the URL and IP address of CRM 2013 will be different than CRM 2011, which will require that Outlook Clients be reconfigured to the new URL, or existing URL DNS entries will need to be remapped, which will make CRM 2011 no longer available. Given that DNS entry changes can sometimes take several hours to take effect, this can result in multiple hours of CRM being unavailable.

Import upgrade

With this option, CRM 2013 is installed on a fresh set of CRM and SQL servers. A clean (empty) CRM installation is performed, then a backup of the CRM 2011 database is restored to the new CRM 2013 SQL Server, and the organization is imported via the deployment manager MMC console snapin.

Benefits of Import upgrade:

  • Cleanest, least destructive upgrade option
  • No artifacts from previous version on CRM or SQL Servers
  • Since this option is nondestructive to your CRM 2011 environment, this upgrade option can easily be redone multiple times prior to your production environment. After installing CRM 2013, the database from CRM 2011 is imported and upgraded. If the import upgrade fails, you can drop the imported organization, resolve the issue, take another production backup, and try it again. At no point does the CRM 2011 production environment get disrupted, until the upgrade is complete and verified, and CRM 2011 is turned off.
  • Less downtime for CRM users, as you can complete the CRM installation on the new CRM 2013 servers well in advance of the actual upgrade. This allows you to test and upgrade your customizations prior to the production upgrade, then when ready to go-live on CRM 2013 in production, import the final upgrade into your environment. This results in the users being out of the CRM application for a significantly shorter period of time.

Risks of import upgrade

  • Added expense from having to provision new servers or virtuals for CRM 2013.
  • CRM is installed on a different server, so Outlook clients will need to be reconfigured, or DNS entries will need to be remapped.

The import/upgrade option is Microsoft’s recommended approach for upgrading to Microsoft Dynamics CRM 2013.

Tip #197: Don’t forget the cascading

You implement Microsoft Dynamics CRM and create a custom entity called “Account Review” as a child of the account entity. This entity is part of a sales management account review process. You make the entity relationship parental so that deletions and re-assignments of account records will cascade to related Account Review records.

Five years later, when you upgrade to a new version of CRM, you notice that the Account Review records are not really being used–some use it, but it was a good idea that never really was adopted by sales managers. You don’t want to delete all of the data in the entity, but to simplify, you remove security role access to the entity and remove it from the sitemap so users won’t see it.

After the upgrade you notice that your ERP integration that updates accounts is failing. The reason is that the user that the integration process is assigning the account to doesn’t have permission to read the related Account Review entity. But the integration process doesn’t reference that entity. What’s happening?

The reason for the error is because the Account entity has a parental relationship with Account Review. When updating records that have associated Account Review records, when a record is reassigned, the assignment cascades to the related Account Review records. If the user to whom the Account is being reassigned does not have permission to read the custom entity (since we removed it from their security role), the update step will fail.

Lesson learned: When updating an existing customization and removing entity permissions from a security role, always verify if there are any parental or configuring cascading relationships with that entity, and if the users with that role will ever have a parent record assigned to them. if that is the case, change the relationship to configurable cascading and turn off cascading for assign.

Tip #196: Why can’t I funnel or pie?

I received an excellent question this morning:

“Dear Tip, why can’t I do a funnel or pie chart? These buttons are grayed out!”

chartcategory

The reason the buttons for funnel and pie are grayed out is because the chart definition includes multiple categories. Pie and funnel charts only support single groupings (series and category). When doing multi-series or multi-category charts, you should use a bar or line chart.

 

Tip #195: Recurring goal creation strategies

The goal functionality in Microsoft Dynamics CRM is very powerful, but in my opinion, is not used as often as it should be. One of the reasons for this is because goals do not recreate themselves–you must recreate them for each time period. This can be very cumbersome, especially if the time periods are short. If someone has to manually type in goals every week, chances are they aren’t going to do it.

The good news is there are ways to make goal re-creation more automated. The following are three approaches.

  1. Import from Excel: For this approach, create one goal for each user/group. Populate the dates, metric, goal, and rollup fields. Export these records to Excel as a static workbook. This will become your goal template. Each time you want to recreate your goals, update the worksheet, changing the date fields, and the goal value (if the goal for this time period will be different). Leave the metric and rollup fields the same, save, and import to CRM. This approach works well when you want to quickly recreate the goals and maybe change the goals amount for the new time period.
  2. Use a data integration: Using a tool like Scribe or SSIS with Kingswaysoft, create a DTS. Have your SQL query set the appropriate time period and users. Since all goals will include the same metric, specify the GUID of the appropriate metric, and write the goals to CRM. I would recommend creating one set of goals first, then look at how the fields are populated in CRM. This way you can be sure that your data load populates the appropriate fields. Using this approach, you can create a scheduled job that runs on a scheduled basis and automatically creates the goals for the new period.
  3. Use a workflow: With a little bit of customization, you can create an entity to serve as the goal scheduler, and a workflow that will automatically recreate goals for you. I have documented this process in this post.

Bonus tip: Make sure that you periodically “close” completed goals. This freezes the goal value, and prevents performance impact from CRM having to keep recalculate completed goals.

Tip #194: When automatic update is not your friend

tl;dr

Nuget is a great tool and a real timesaver but beware of automatic updates that can unexpectedly bring incompatible or broken builds of third-party libraries and that will, in turn, break your plugins or workflows.

The real story or “I saw the whole thing”

Friday, August 1st, 6:00PM

All users logoff and CRM is up for a good scrub over the weekend. It’s about to get an upgrade to the latest version of code that has been in development and testing for a few weeks now.
Continue to the full scoop

Tip #193: Check your duplicate detection rules after solution imports

Today’s tip was submitted to the tip jar by Jef Smets. Got a tip that you want to share? Send it to jar@crmtipoftheday.com.

For quite some time now our duplicate detection rules seemed to be un-publishing themselves from time to time… Nobody had any idea why until I discovered today that duplicate detection rules are unpublished when you import a solution (!). So, every time you import a solution you need to check your duplicate detection rules.

Also, if you have add-ons installed with an auto update functionality you want to check your duplicate detection rules after each auto-update. We have the ClickDimensions solution installed and this solution has such an auto update mechanism. After each auto-update the duplicate detection rules are unpublished and I need to publish them again.  The good news is that ClickDimensions sends me an email after each update and that the unpublish action is record in the modified on and modified by (SYSTEM) field so you can easily filter the rules to need to be published.

Tipp Jarr’s note — the same applies to audit settings. It’s a known challenge for ISVs, hopefully it will be addressed soon.

Tip #192: Defensive script writing

(Today’s tip is actually two-in-one but we’ll get to that.)

Over the years as a CRM jackofalltrades I learned that to create truly reusable, bug-free and resilient systems is very important to write your scripts as if the next team member, who comes after you, dedicated their entire career to destroying your life’s work.

Consider the task: add a new Age attribute to the contact record and set it’s value based on birthdate attribute. Easy, right?

function setAge() {
  Xrm.Page.getAttribute("foo_age").setValue(
    calculateAge(
      Xrm.Page.getAttribute("birthdate").getValue()
    )
  );
}

function BirthdateOnChange() {
  setAge();
}

Some time later users report the following message being displayed every time they enter birthdate field:
Script error message

As it turns out, one of the junior customizers was given a task to create a new form which is a simplified version of the existing one. After opening the form and using Save As function, they’ve got the exact replica including form scripts and events. Then they proceeded to cleanup the layout as specified by the business and that included removing Age attribute. And they did not test because the existing form they copied works perfectly.

How this fragment could have been written so it does not crumble when a user sneezes? One of the options:

function setAge() {
  var ageAttr = Xrm.Page.getAttribute("foo_age");
  var bdAttr = Xrm.Page.getAttribute("birthdate");
  if(ageAttr != null && bdAttr != null) {
    ageAttr.setValue(
      calculateAge(bdAttr.getValue()));
    )
  );
}

function BirthdateOnChange() {
  setAge();
}

That way, code at least does not bring the form down when one of the attributes is removed. It’s also considered a good practice to explicitly add dependencies for the specific event handler (BirthdateOnChange in our example):
Event Handler Dependencies

One may argue that the example is trivial and bug should have been picked up by testing. Indeed, it’s a simplification but the best practice has always been to program defensively as if the next in line is malicious, ignorant or both.

As for the bonus tip, here is how to calculate age in javascript:

function calculateAge(bd) {
    if (!bd)
        return null;

    var today = new Date();

    var bmonth = bd.getMonth();
    var bday = bd.getDate();
    var nowmonth = today.getMonth();
    var nowday = today.getDate();

    var age = today.getFullYear() - bd.getFullYear();
    // take into account if this year birthday 
    // is later in the year
    if (bmonth > nowmonth 
      || (bmonth == nowmonth && bday > nowday)) {
        age = age - 1;
    }

    return age;
}