Tip #243: If you lost your encryption key

In Tip #241, we recommended backing up your encryption key for CRM 2013. What if you didn’t do that, and now you have lost your encryption key.

There are several things that you can do. First of all, you cannot enable encryption in the organization if you don’t have the original key are there is data in the encrypted fields. But you can enable encryption if you delete the encrypted values or delete the records that contain the encrypted values.

You will not be able to open up the records with encrypted fields if the encryption key is not present, but you can delete the values via the web services, or using a tool like KingswaySoft SSIS adapter.

You can also delete the records that have the encrypted values. This includes the following entities:

  • Mailbox
  • Email Server Profile.

After deleting these records, you should again be able to enable encryption.

Tip #242: Don’t forget the default filters

Are your users confused when a CRM report freshly-minted by a report wizard, does not deliver the data they expect?

Inspired by our twice the tip, our fellow contributor Andre “I’ve got 88 in my handle” Margono sent us a fresh reminder that “the default filter is something that I often forget to remove/update and causing some confusion to the end user when they expect more data to be included in the report.”

Default Report Filter
From the authoritative source:

When you publish a report, you can set a default filter. For all the reports that were created by using the report wizard, if you do not set a default filter, the filter is automatically set to all records of the entity modified within the last 30 days.

Tip #241: Back up your encryption key

Dynamics CRM 2013 has field level data encryption on password fields, like the email password field on mailbox records. This feature is enabled by default.

Always be sure that you copy the key and save it in a safe place. You will need it some day.

When you import a copy of an organization in your CRM On Premises deployment, the key will not be regenerated. This means that if you don’t have a copy of the key, you won’t be able to use e-mail or access mailbox records.

Consider the following scenario: you “refresh” your dev environment with a copy of production. After you import the organization, the restored organization will not contain the encryption key, so you will not be able to access mailbox records with encrypted passwords. This is not the end of the world, because you can log in to the original organization, go to settings–>Data Management–>Data Encryption in prod, copy the key, then go and paste it in to dev.

data encryption

But what if you reimport the original organization? Say your CRM server dies, and to restore you do a clean installation of CRM and import the organization from the original database? In this case, you will lose your encryption key and won’t have a place from which to retrieve it.

That’s why I strongly recommend that you keep a copy of the encryption key from every organization in a place where you will be able to find it when you need it.

 

Tip #240: Once bitten, twice filtered

Anything that’s been done twice is usually better. That includes double cream and double barreled. Except that report pre-filtering does not work if you need a filtering entity to be included more than once in your SQL.

Consider this totally random piece of SQL:

select 
   a.revenue / b.revenue 
from 
   FilteredAccount a 
   inner join FilteredAccount b 
   on a.parentaccountid = b.accountid
where 
   b.revenue is not null

You cannot just apply pre-filtering because alias CRMAF_FilteredAccount cannot be used twice in the same statement. Not the most efficient but reasonable workaround includes temporary tables to get filtered records first and then use them as needed.

declare @accounts table(accountid uniqueidentifier)

insert @accounts select accountid 
from FilteredAccount CRMAF_FilteredAccount

select 
   a.revenue / b.revenue 
from 
   FilteredAccount a 
   -- apply filter to accounts
   inner join @accounts a1 
      on a.accountid = a1.accountid
   inner join FilteredAccount b 
      on a.parentaccountid = b.accountid
   -- apply filter to parent accounts
   inner join @accounts a2 
      on b.accountid = a2.accountid
where 
   b.revenue is not null

Time for double distilled.

Tip #239: The undo button

When you are working in an application like Excel and you accidentally type over some important text, isn’t it great to be able to hit the “undo” button? Don’t you wish that Dynamics CRM had an undo feature?

It can, with the help of Jason Lattimer’s nifty Audit Undo solution.

As long as the user has permission to view audit records, and auditing is enabled for an entity, a user can view the audit logs and undo changes to roll them back.

Note–while this tool is almost a year old, it is still super cool. Plus, I didn’t notice it when it came out because I didn’t need it, but then somebody made some changes that they shouldn’t have. Keep it in your back pocket–you will probably need it someday.

Tip #238: My workflow is my business

Hey, everybody, Larry’s opportunity pipeline this month is again bigger than everyone else’s. Larry, what’s your secret?

Larry, being somewhat softened by reasonable quantities of flavored C2H5OH, was more than happy to share his fortunes:

It’s all about power of automatic workflows, my friends. See how I automatically increase opportunity value the moment it’s created?

Opportunity Workflow

But if it’s automatic how come our records stay the same?!

No idea, but it works for me!

The secret sauce, of course, is frequently overlooked scope of the automatic workflows.
Workflow scope
If user creates a workflow and sets the scope to, ahem, User, then this workflow will only kick in for the records owned by this user. This setting, frequent source of workflow creators’ frustration, is a powerful tool to create private functionality scoped to individual, business unit, business unit and children, as defined by the current workflow owner and her business unit.

One useful application of that feature is ability to craft your workflow in production right under the nose of unsuspecting administrators. Set the scope to the user, work on your private records, make sure the workflow works as expected then change the scope to, say, organization.

Tip #237: When moving data, keep the record ID

When you are migrating data between two CRM environments, such as going from CRM On Premises to CRM Online, one of the best things you can do is move the record ID (GUID) of the records. This way, if you have a relationship or a lookup field that references another record, you will not have to do any transformation or lookups to resolve the record ID–you can just move it via straight insert.

The same applies to user ID’s. If you use CRM On Premises, you can create user records using data migration/integration tools like Scribe Insight or SSIS + Kingswaysoft. Since every record has user relationships, like ownerid, preserving the unique identifier of user records will dramatically simplify your migration.

However, be aware when you do this that there are some fields that are only populated on user records for CRM Online deployments. In a recent migration moving data between two CRM On Premises environments, when moving the user records was attempted, the migration DTS returned the following error:

“This is not a valid Microsoft Online Services ID for this organization.”

Turns out that one of the organizations was originally a CRM Online environment that was moved On Premises. Removing the following fields from the DTS mapping made the user record migration work successfully.

  • islicensed boolean(1)
  • issyncwithdirectory boolean(1)
  • invitestatuscode integer(4)
  • windowsliveid nchar(1024) 

Thanks to Evan Watson for input on this tip.

Tip #236: How to be a time[r] lord

Spring ’14/SP1 release has introduced a number of very exciting features to the customer service functionality of Dynamics CRM including Service Level Agrements and Entitlements. The decision also has been made to introduce Spießrutenlaufen, previously reserved for developers, to the customer service officers. Yes, I’m talking about timer control

Xrm.Page
  .getControl('foobar')
  .getControlType() == 'timercontrol';

The other good news is that this control can be dropped on any entity’s form that has a date/time field (well, there is always createdon and modifiedon) and an optionset.

Tired of long meetings running over time? Drop timer control on the appointment form:

Timer Control

and keep the form open during the meeting, control will turn change color (pantone code “nasty red”) once you’re over the line:

timerover

And meeting is a success only when it’s over:

timersuccess

Tip #235: Avoid over-use of required fields

Many a CRM customizer has decided to make a bunch of fields on a form required in an effort to force users to at least submit a minimal amount of information when creating a record. But could it be that by requiring many fields you are actually getting less information than if you didn’t require all those fields to be completed?

I came across some research from the University of Cambridge on the voluntary over-disclosure of information in web forms. Researchers found that users completing forms will naturally over-disclose information that is not required when completing web forms. Surprisingly, the more fields on the form that were mandatory to complete the form, the fewer optional fields were completed by users. It seems that mandatory fields get more attention from users, causing them to ignore the optional fields.

Granted, there is a difference between a web form and a CRM form, and there are certain fields that have to be populated for business processes to run successfully, but I think there is a case to be made for limiting unnecessary use of required fields. By requiring many fields, you may be conditioning your users to only submit the minimum amount of information.

Tip #234: Beware of the IOS 8.0.2 update

If you use an IOS device, you know that there have been many updates recently. The IOS 8.0 release on September 17 was shortly followed by the 8.0.1 update. This release broke many user’s cellular connections, so Apple rushed out the 8.0.2 update to fix the issues introduced in 8.0.1.

So what does this have to do with Dynamics CRM?

If you are running the CRM for Tablets app on your iPad, you should be aware of the impact that upgrading your iPad may have on the tablets app. First thing, IOS 8 is not officially supported. This doesn’t mean that it won’t work. I’ve tested it extensively, and I have not seen any issues.Until updating my device to 8.0.2.

If you have CRM for Tablets installed on your iPad and you install 8.0.2, you will notice that the screen appears “stretched,” and that the more options (…) button is not displayed. This will significantly limit usability of the app.

If you have already installed the update, removing the CRM for Tablets app and reinstalling it should return the more options button and make the app once again usable. If you have not installed the 8.0.2 update, you will probably want to hold off until the app has been updated to address this issue.

Bigger picture, train your users to not automatically install every update the minute that it is released. Wait until you test the CRM app on a device with the new update on it. Just like Windows updates on your PC’s, mobile OS updates can introduce new issues and cause unplanned downtime for users if these updates are not tested properly with mission critical apps.