Tip #503: Tipster guide to USD Window Navigation Rules

It’s Friday and time for another video. In our last of Intro to USD configuration series we explore Window Navigation Rules. Derik walks you through what they are, how USD uses them, and how to create them.

YouTube player

Give us your feedback, all of it: good, bad, and ugly, I’m sure we can take it. Suggest new topics either in comments or by sending your ideas to jar@crmtipoftheday.com.

Tip #502: Who moved my activity

tl;dr

When record ownership is important, use synchronous workflow that impersonates the caller.

The Stop

Dynamics CRM TipperOne of the signs of greatness professionalism is not to be afraid to ask questions, no matter how trivial or silly they might sound. Mitch “Only in Texas” Milam has the microphone:

Q

Activities ownershipHi Folks,

This is such a basic question that I am almost too embarrassed to ask – but not that embarrassed.

I have a workflow that is closing phonecalls and when you look at the activity history, you see my name as the Completed By because I am the owner of the workflow.

Any way around that?

A
Gustaf “Eat more herring” Westerlund has the floor:

Hmm… synchronous workflows can be set to execute as the user who initiated the event. [speculations about performance removed – t.j.]. Creating a custom workflow activity which closes it with the user of the last modified, might be an option.

1000 words

Workflow ownership

Tip #501: Should you use the lead entity?

In Dynamics CRM, the Lead entity is designed for potential clients that are qualified by a salesperson prior to becoming Accounts, Contacts, and Opportunities. Once qualified, CRM creates Accounts, Contacts, or Opportunities. After the salesperson speaks with the potential client, if there is no interest, the lead is “disqualified,” which deactivates the lead record.

When used in this manner, the lead entity can be useful. However, it can cause some issues if it is not used properly.

  1. Leads are like perishable products or smelly fish at the grocery store—they should not get old. The longer a lead sits in the lead entity, the more likely it will be that data issues will arise.
  2. When a lead is “qualified,” it is deactivated and most of the data is moved to a contact and account. However, not all data is moved. For example, notes associated with the lead are not moved to the contact. You can use plugins to move the missing pieces, but it is incomplete by default.
  3. There is no sure-fire foolproof way to do duplicate detection between leads and contacts. This makes it highly likely that a lead might get created for an existing contact, duplicating the identity of the person in CRM.
  4. When you disqualify a lead in CRM, the lead record is deactivated. If that person calls back in 6 months with renewed interest, most likely the salesperson will be unaware of the old lead and not know the previous interactions with that potential client.
  5. When you qualify a lead in CRM 2013/2015, you are forced to create a contact and an opportunity. Not all CRM users want to always create an opportunity and a contact. See http://www.pedroinnecco.com/2013/10/lead-entity-2013/.

For these reasons, many companies elect to not use the lead entity for prospect management. One common alternative is to use accounts and contacts for prospects and leads. Using the “relationship type” field you can define a type of “suspect” and “prospect,” and flag prospective customers appropriately. Once this is in place, views can be configured so that leads are excluded from the customer views. The benefits of this approach:

  • Better duplicate detection
  • No loss of data when converting leads
  • Marketing lists can include both leads and customers
  • More flexibility over when opportunities and contacts get created.

So who should use leads?

Based on the points above you may think that I am anti-lead. I do see several types of deployments where leads are favorable.

  • Environments with web form integrations that get many submissions with “Santa Claus” or “Mickey Mouse.” In these cases, the lead bucket may make sense to avoid introducing invalid contact data into your contact entity.
  • Environments that import heavily from trade shows or other high-junk information sources.
  • Organizations that have an individual or people that call potential clients only for the purpose of qualifying them (thanks Donna Edwards).

One more thing: Cross Entity Process Flow

The introduction of cross entity process flow in CRM 2013 does potentially alleviate some of the potential risk of using leads. This allows a user to see the qualified lead and the opportunity in the same process flow, making it more of a unified process. However, this does not take away the issues with leads and other data not converting, it just makes it easier for users to navigate between the qualified lead and the opportunity. http://canada.hitachi-solutions.com/blog/dynamics-crm-cross-entity-business-process-flow/

Tip #500: Captain Redlaces’ Mobile Manifesto

500th cakeWhat would be the better way to celebrate our 500th tip than to welcome Scott “Captain Redlaces” Sewell as our residential tipster? He opens strongly, not with just a tip but a manifesto.

Dynamics CRM App for Mobile (phone/tablet) October 2015 edition

Mobile Manifesto

The mobile apps are great.

There’s a lot to like about them – That said, translating the CRM experience to a Mobile application results in some design compromises due to the difference in form-factor and size/capacity of the devices.  Additionally the Dynamics CRM App for Mobile is a fairly young feature and I expect the feature set/design to rapidly evolve with the platform and with the capabilities of mobile devices.

This list is just a point-in-time as of October 2015, and many of these items are already in the pipeline for fixing or enhancements in the 2016 version or soon thereafter. –

For several I’m including a link to other Tips with more explanation and some workarounds – And for some I’m linking to the Microsoft Connect page where you can ‘vote’ and comment on the issue to help raise awareness of it within the product team. – (If you’re not already registered for Connect, it’s free, easy, and gives you a voice in shaping the direction of the product.)

Critical:

  1.  Filtered lookups do not work on the tablet. See Tip #274 (See and vote on this Connect item – Support Filtered Lookups for Mobile Apps (iOS/Win) )
  2. The ‘default’ view in an associated view is not the Associated View like it is in CRM – it’s the entity default – leading to confusion between the clients. (See and vote on this connect item – Associated records are displayed with the ‘Associated’ view in the web and the entity default view on the Mobile clients. (iOS/Win) )
  3. Subgrids default to the nearly universally incorrect ‘Add-Existing’ behavior – this is different than the Web client. – Additionally, the Add-Existing option can’t be removed in the tablet (like it can in the web client) (This is anticipated in the next release.)
  4. We need the long awaited web resources (e.g. CRM Posts, Yammer, LinkedIn, etc.) to work. (The first release of this is anticipated in the 2016 app.)
  5. Personal views “shared” to an individual are not visible on a Tablet – (Personal views shared to a Team are displayed, so share any personal view you want visible on the tablet/phone to a team instead of an individual.) (See and vote on this Connect item: Views shared to an individual are not available on the Mobile Client (iOS / Win)
  6. Any field configured as “Multiple Lines of Text” (e.g. the message body of emails or appointments or the “Description” field on Accounts, Contacts, Opportunities, and Cases) is only partially visible on the tablet and the user’s experience when reading /editing the text is extremely limited. (See and vote on this connect item: Expand the multiple-lines-of-text field’s read/edit window on Tablet Application and fix the word-wrap)
  7. Appointments created in the iOS App get a status of “Open” and are editable in the App and the web – however, appointments created from the Web or Outlook clients get assigned a status of “Scheduled” and are non-editable in the tablet, but are editable in the Web Client. See Tip #491 (See and vote on this connect item: Appointments Created in Web or Outlook are Read-Only in the Mobile Applications. (Status = “Scheduled”) )

Important

  1. The ‘Name’ field is required and prominently displayed in views on dashboards/subgrids (even when it’s not the most important/relevant field to show) – As a configuration, you need to plan for the ‘name’ field as if it’s the ‘headline’ for the entity to allow a user to determine at-a-glance what the record represents. – See Tip #495
  2. The default dashboard currently defaults to ‘Sales’ regardless of the default in CRM – and the sales dashboard cannot be restricted/hidden without throwing errors in the Mobile App. (This a known issue and we’ll see a fix in an upcoming release, but until then just work with this knowing that you have a single default dashboard and you can configure it to be ‘generic’ and try to make it appropriate for all users as a general first dashboard.)
  3. Navigation sections are not configurable/manageable – the sitemap is displayed in a seemingly random order. (I think there is a fix in the works for this.)
  4. The field layout is inconsistent with the web-app resulting in a jumbled order of fields – (Rather than a using Sections with multiple columns, use Tabs of Multiple Columns containing multiple single-column sections.) See Tip #497 for an explanation/workaround
  5. Tweaks to the ChartXML work fine in the Web Client, but do not render in the Mobile client (e.g. applying a custom label / interval.)
  6. Configuring the sitemap to display/hide some elements based on permissions works in the Web client, but it is not honored in the Mobile app. See Tip #466
  7. The form used on the Mobile Client is just a render of the user’s main form – it’s not a ‘special’ mobile-oriented form. – This allows you to “configure once” – but leads to compromises since some entities only need a bit of summary information pushed to the mobile devices – but need a much richer layout in a form consumed on a web page.
  8. There is a current bug that throws an error whenever you attempt to ‘sort’ in a mobile grid by tapping on the column heading – IF you have 2 columns defined as the default sort order that view. See Tip #441 (There is a fix in the works, but if you really run into problem with users throwing an error when they search, just remove one of the two sort-columns until a fix is available.)
  9. Lookups only search against the ‘name’ of the entity – despite the quick-find configuration and the behavior in the web client. – See the Bonus Tip added to Tip #274 – Additionally the asterisk ( * ) wildcard is not supported on the Tablet, but rather the tablet uses the SQL standard percent sign ( % ) as a wildcard. (See and vote on this Connect item – and this one Alternative search should work in the CRM for tablets app on lookup fields search)

Annoying

  1. Custom icons are not available on the mobile client.
  2. Tiles for custom entities are all identical green squares.
  3. Charts are sized too large to fit in the panes in Dashboard and cannot be fully seen without scrolling up and down. (I believe there is a fix in the works for this)
  4. The “Case” of view names gets changed to “Titlecase” which messes up CamelCase nouns and ALLCAPS abbreviations like YTD/MTD/LTM in views. (See and vote on this Connect item – Case Sensitivity in Views displayed in iOS app (tablet) )
  5. The ‘Name’ field for each entity is required to be in the view in order to open a record from a web view on a tablet. (This is mostly a limitation since there’s no double click in Safari on the iPad. – The ‘Name’ field serves as a hyperlink to the record in Safari.) – See Tip #495
  6. “Pinning” tiles to the ‘Home’ or a dashboard view is GREAT – unfortunately that information is cached locally and does not transfer from your phone to your tablet or vice-versa – Also, if you ever log-off the device, you lose your ‘pin’ configuration for that device. (See and vote on this Connect item – Records that are pinned to the Home page do not show up when the CRM App in iPad is reconfigured )

Maddening

This is My Number one issue – If you do anything to CRM’s configuration and publish arbitrarily or with any regularity – every mobile user will (justifiably) hate you for 4-6 minutes while they update their metadata.
Any ‘publish’ at the server causes each mobile device to prompt the user to download the latest metadata – which depending on the speed of the device and connection could take 4 minutes or longer to complete during which the user can’t really use their phone.
Mitigation of impact:
1) Train users to ‘ignore’ the download prompt “if they’re busy” – (This approach could easily train users to /always/ ignore the prompt and wind up with significantly outdated metadata.)
2) Limit the updates to CRM to only once-a-month or once-a-quarter. – (This is a best practice, but requires a disciplined approach to the process of deploying / updating CRM.)

Tip #499: Outer joins and dashboards

Another gem from Scott Sewell:

If you edit the FetchXML query of a view, you can change the view query to an outer join, enabling you to see records “not in,” or records that do not have a relationship.

When you do this, the view is available from within CRM, but cannot be selected for a dashboard view or chart.

The Captain Redlaces workaround:

  • Create the view but DO NOT modify the query to an outer join.
  • Add the view or chart to the dashboard.
  • Update the view query to an outer join.

Tip #497: Avoid multi-column sections if using mobile

Another awesome TIL from Scott “Captain Redlaces” Sewell.

tl;dr

Avoid multi-column sections on your CRM forms. (If you’re going to use the Mobile Apps)

Today I Learned

If you’re going to use one of the mobile apps in your implementation, avoid using multi-column sections – the layout of these fields will be significantly different from the Web app.

Use multiple column Tabs with multiple sections – rather than a single-column tab with multi-column sections. (Multi-Column sections display in a different sequence (across then down) on the tablet apps and create a ‘mixed-up’ view of the section.)
Multi-column tabs and sections
Here’s a view of a sample record in the Web Form showing the Tab-Order.
Field flow on the web
Here’s the same form in the Tablet App – notice the how the Tab with 3 Columns translates better to the app’s default layout.
Field flow on mobile

Tip #495: Include “Name” as first column in views for mobile or Safari

We now have so many tips coming from Scott “Captain Redlaces” Sewell that the pressure is mounting to add Captain as ah honorary tipster or, at very least, dedicate a category for him. As suggested by the man himself: “TIL”.

Today I Learned

If you’re going to use mobile App or Safari – best practice is to include the “Name” field in the view if the view is to be used on a tablet.

It makes sense to include the “Name” as the first column in your views for 2 reasons –

  1. The Name is always listed as the first (bold) line for each record in dashboards lists in the Tablet Apps (See picture)
  2. Unless you have the “Name” field in the view, you can’t open that record from the view on an iPad in Safari. – (because on the iPad you can’t double-click, you can only open records where you have the “name” field visible – admittedly it’s an edge case, but we were promoting ‘open the record in browser and you can see the related records in the subgrid – as a way to deflect trying to put every record in the app. – but we found that they couldn’t open those records in the subgrids b/c there was no link to them. – we added the “name” and like magic the design is approved.

    3. Name as the first column

Tip #494: Outlook Sync Filters where are they?

Finding the spot where you can set the filters to determine the CRM records that are synched to Outlook or your Exchange folders isn’t as intuitive as it could or should be.

When in Outlook and you go to File, CRM, you are presented with a screen which gives you the options to set the offline filters. But where is the option to set the record types to sync to CRM when connected via the client?

That is three more clicks away and not readily observable. You get there by clicking on the Set personal Options button and then clicking on the Synchronization tab and then clicking on View or manage the filters …

Set Personal Options

Set Personal Options

Synchronization using Filters

Synchronization using Filters