What 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

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.)