Setting Multi-Level Categories Against a Record Codelessly

This is a bit of a variation on a theme I did a while ago when I talked about using filtered views for address population. In this case I wanted to explore if we could set up a subject-like hierarchy and then use filtered lookups to enter category levels easily against an account. It turns out it works quite nicely.

Essentially, you set the first category from you list of top level categories. Then, you set level 2 which will automatically adjust to only the valid values, based on the category 1 value. Finally, you set the category 3 value, based on the value in category 2.

So How Do I Set This Up?

First of all, we create a new Category entity.

In this case I have stripped everything out; there are no notes, activities etc. and the record is organization owned.

Next I set up a recursive 1:N relationship so that for a given category I can set an infinite number of category levels, each with an infinite number of categories.

The main points of interest here are the changing of the display name to ‘Parent Category’ and the changing of the display option to ‘Use Custom Label’ so I can refer to the next level down as ‘Sub Categories’.

On the category form I also add the parent category lookup, created as a result of this relationship.

Finally, I add three lookups to the account form so I can add three levels of category to my account record.

Finally, I populate my category hierarchy. Unfortunately, there is no nice tree view to employ so I fill it up in pretty much the same way I would if I was populating, for example, an account hierarchy. My advice would be to do it via a data import.

Where’s The Magic?

So far this will just let us pick three category values from all category values and add them to an account; not exactly exciting.

The trick comes in adjusting the filters on the lookups.

For category 1, we set up a new system view called Level 1 Categories. This just shows those categories with no parent category i.e. they are at the top of the tree.

We then go to our first lookup and force it to only use this view for its values.

The result is when we click the lookup only the values in the top level appear.

For the other two lookups, we use the Related Records Filtering properties of the lookup. For the category 2 lookup, we set it as follows:

The setup for the category 3 lookup is identical, except we replace ‘Category 1 (Accounts)’ with ‘Category 2 (Accounts)’.

This means, clicking on, say, the category 2 lookup shows only the valid values, based on the selection for category 1.

And that is it. With all that set up, all the user has to do is pick the category 1 value and the category 2 values will be auto-filtered. Once the category 2 value is selected, the category 3 values will filter.

Why Not Use Subjects?

Subjects are nice in that they can be linked to an account with a 1:N relationship and they have a tree view lookup. However, they do not, at this time, play nicely with lookup filters. If you add a subject lookup to an account form and try to filter its values, based on the selection in another subject lookup, CRM throws an error. This has been reported and, I am sure, will be addressed in a future roll-up.

Conclusions

If you have a multi-level hierarchy you wish to apply to a record, such as an account, and you are looking for a reasonably user-friendly way to capture the information this is not such a bad solution and does not require code or Silverlight web resources. While my first choice would be the subject entity, because of its friendly tree view, if this is not practical, this solution provides an alternative approach which supports any number of category levels.

Trying a Different Language By Ticking The Box

Dynamics CRM supports 41 languages. Here they are:

• Arabic
• Basque
• Bulgarian
• Catalan
• Chinese (Hong Kong SAR)
• Chinese (Simplified)
• Chinese (Traditional)
• Croatian
• Czech
• Danish
• Dutch
• English
• Estonian
• Finnish
• French
• Galician
• German
• Greek
• Hebrew
• Hindi
• Hungarian
• Italian
• Japanese
• Kazakh
• Korean
• Latvian
• Lithuanian
• Norwegian (Bokmål)
• Polish
• Portuguese (Brazil)
• Portuguese (Portugal)
• Romanian
• Russian
• Serbian (Latin)
• Slovak
• Slovenian
• Spanish
• Swedish
• Thai
• Turkish
• Ukrainian

So how do we turn on different languages? Well, if we are using Dynamics CRM Online with the web client, we literally just tick a box. Go to Settings – Administration – Languages and tick the box for the language we want.

Curious to see how Spanish looks? Tick the box. After a little whirring, you have your second language installed.

As a user, you then go to File – Options – Languages and pick the language you want.

That’s it! You are now working with Cuentas y Contactos rather than Accounts and Contacts.

What if you are using the Outlook client or an on-premise deployment?

In the case of the Outlook client, you need to install a language pack on the client machine. Similarly, with an on-premise deployment, you need to install a language pack on the server.

However, for online, having CRM configured so that you can be working in one language and the person next to you is working in a completely different language is literally a tickbox away.

Moving To The Cloud Part Two: Migrating Email To Office 365

For part one, where I talk about my reasons for jumping on board with Office 365 and how I got a 25% discount on the cost, go here.

In summary, I had a 12G PST accumulated over about 12 years of emailing with Outlook. The regular backing up and periodic maintenance of the PST file (running the Inbox repair tool once a month, compacting etc.) simply never got done due to a lack of time/inclination. I needed a better solution and I was willing to pay for the privilege.

Office 365 was a good fit. I get 25G of storage in Exchange and, the hope was, it would be a relatively simple procedure to move from a PST file to an online version of Exchange with a local OST file for offline access (OST is a local cache of your Exchange content which automatically syncs with Exchange when online). I also had two gmail accounts and one hotmail account to repoint to the Exchange server as the PST file would be decommissioned completely. In other words, other than the OST file, which could be rebuilt automatically from the Exchange server, all my e-mail was in the cloud.

Connecting to the Cloud Exchange

I run Office 2010 at home so connecting to the Cloud Exchange was very simple. Go to File-Account Settings-New and you then type in your name, e-mail address and password.

Outlook does the rest. Outlook will give you a new folder with the usual sub-folders (Inbox, Tasks, etc.)

Moving Stuff Across

First of all, backup/copy your PST file. If everything goes badly, you still have that to fall back on. It is then a case of populating the new Exchange folders with the stuff from your current PST folder structure. For e-mail, I either dragged e-mails across or used the move/copy folder function of Outlook.

What then happens is the folders/emails are moved across to the local OST file associated to the cloud Exchange server. These e-mails and folders are then, in the background, synched up to the cloud Exchange server. I loaded my sync up pretty heavily and it seemed to survive fine. Even if I shut down and restarted later, all was good.

For things like calendar/contact entries, I usually switch views to a list view which lets me easily highlight all records at once. I had some trouble with calendar entries as it would not let me select all calendar entries at once, only those of the same recurrence, but this was sufficient to get all entries across in a timely fashion. The only ones which would not come across were 2003 appointments which it claimed had ‘invalid parameters’. Given I only had a handful of these, it did not concern me. The other thing to note is it will warn you that appointment updates will not affect the appointments you move across; the link is effectively broken if the meeting organiser sends through an update. For me, this happens very rarely so it did not concern me.

Also, I am told there is every possibility that CRM tracking will also break when you move things across to the OST so this is something to be careful of.

One really nice feature was, when I moved my RSS folders across to the OST, the settings (which are held in Outlook and cannot be transferred to Office 365) automatically redirected to the folders on the Exchange server. The upshot is, while RSS feeds will only update when I open Outlook, they will populate directly onto the cloud Exchange server via the local OST file.

This was not the case for TwInbox, which I use to bring my tweet feed into Outlook. In this case I had to create new folders on the Exchange server, redirect the TwInbox settings to the new folders and move across the existing tweets. Like the RSS feeds, as TwInbox resides within Outlook, my tweets will only update when Outlook is open.

My search folders also had to be recreated on the Exchange server.

One word of warning, I had some weird archive behaviour (settings adjusting themselves during the transfer) so make sure these settings are as they should be one you have set everything up.

Initially I thought I had lost my Outlook rules but this was only because, if you change the default location for e-mail, they disappear from the list. If you reinstate the old location, they re-appear. You can then copy them to the new account. If you remove the PST file from Outlook though, the rules are lost forever, so copy them before this happens. While I remembered this for my gmail accounts, I was not as careful with my hotmail account and had to reconstruct those rules from scratch.

I also lost my quick steps, which I use heavily, by switching default folders, and did not work out how to retrieve them, so be careful to note them down before switching across.

Once the rules and quick steps have come across you can repoint the default location to the Exchange inbox and remove the email addresses from the local Outlook and add them to the Office 365 server.

Adding The E-mail Accounts To Cloud Exchange

This was also really simple. You log into Office 365 and go to Outlook-Options

From here, click on ‘Connected Accounts’ and click the ‘New…’ button.

It is then a case of typing in the e-mail address and password and Office 365 does the rest (or at least it does for gmail and hotmail).

Assuming the accounts are no longer in the local Outlook, what then happens is when an email hits your, say, hotmail inbox. It then gets sent over to the Office 365 Exchange server inbox and syncs down to the local OST file on your laptop/PC/windows slate device. This works very smoothly for gmail but, unfortunately, the hotmail inbox e-mails do not get marked as read, even after moving across so every time I log into Instant Messenger it looks like I have a bunch of unread e-mail even though I do not.

The Problems

First of all, the process can take a long time. It is not quick to pump up 12G of data up to the cloud. It literally took me days. although the time it takes is not always obvious (given the local OST is populated straight away). Do not worry about waiting for the e-mails to sync up before switching the e-mail accounts across though as it all seems to work itself out. Outlook/Exchange sync was very impressive in this regard.

Also, while you can send from any of the accounts you link to the Exchange server and replies are smart enough to use the account which the original e-mail was sent to, the default e-mail address for new e-mail cannot be changed and will be the onmicrosoft address that comes with the Office 365 account. Therefore, it is important, for new e-mails, to ensure it is coming from the address you want it to.

One big niggle is gmail addresses are not properly spoofed. What I mean by this is when you send an e-mail, via Office 365, from a gmail address, the recipient will read that it has come from office365account@office365account.onmicrosoft.com on behalf of username@gmail.com, rather than simply username@gmail.com. This is a big problem for exclusive newslists where you are subscribed under your gmail address as any e-mails you try to send to such a list will bounce unless you also subscribe with your onmicrosoft e-mail.

While not a problem as such, note that this setup is not a space saver for the laptop. While we are getting rid of a PST file, it is being replaced by the offline store for the cloud Exchange server, the OST file. What is strange though is that while the new OST is about the same size as the old PST, the space that Office 365 thinks I am taking up is about half.

Here is the OST file:

Here is the quota, according to Office 365.

Go figure.

The Benefits

Obviously I no longer need to back up my PST file because it is now empty and disconnected from Outlook (hooray!)

Also, the trouble I had trying to keep both my personal and work calendars synced with my phone was a nightmare. This problem has gone away. With my workphone, I can link it to my Office 365 Exchange server (I could not link it to my PST file on my home laptop obviously) and to the work Exchange server and it works out the rest. No regular manual synching, no appointment double-ups or conflicts. It just works.

Similarly, it is easy for me to add my cloud Exchange server to my work Outlook and get access to both work and personal e-mails from the office. In this case cloud Exchange will create a local OST on my work computer and I have work and personal within the same program. What is more, if I go offline I still have access to my personal e-mail and all changes will sync when back online; great for plane flights (and no more carrying two laptops!).

I can now check my personal mail via my phone, via my work laptop, my personal laptop or via the web, great stuff.

Conclusions

While there are some niggles (the ‘on behalf of’ thing being the biggest for me) the process of moving everything to the cloud was simple and the benefits of anywhere access without the hassles of backups and maintenance outweigh the issues I have encountered. If you have a big PST file which has you worried about size/corruption issues, this is a great solution for a few bucks per month.

In the next part I will talk about moving my 35G of data to the cloud.