This post continues on from how to create an XRM Solution that only uses out of the box/standard functionality in CRM 2015 and will go through a task list of how to make that awesome XRM Solution of yours work in the Microsoft Dynamics Tablet & Mobile apps. I’ll also try and cover some tips on where you might have to make some process changes because of their own limitations and some suggestions on how to move forward once you have configured them.

Remember, this post is only using my XRM Solution as an example and the points raised it will still apply to other solutions. (Those where the awesome ones I was referring to). 😉

I did not design my XRM Solution to work with the mobile apps, it was purely for the web application. I’ve now decided that I would like to enable it for use on mobiles and tablets. Similarly, this is a real life scenario and requirement and this is why it has been done this way as developing for multiple platforms was not really that big until the last year or so when the official Dynamics apps came out and so wouldn’t have been considered in requirements. Hopefully these lists will be useful for both scenarios where you know before the design/scoping stagethat the solution needs to work for all devices or whether it is an afterthought of the customer so it can  serve as a checklist of reminders that you can go through to enable your applications to be used on other devices using the Microsoft CRM Application.

Where possible, bring it up for discussion with the client about the different device capabilities and the considerations you, as a designer, developer etc, will have to make to ensure the finished solution is ready for all three deployment choices from the start.

Tablet Application Checklist

The tablet application can be found on the Windows Store, and some really useful resources can be found here. See below for the very useful picture on the layout of the forms as they are quite drastically different than the web application. You can swipe left, right, up and down depending on where you are in the form. To bring up ‘actions’ on what you can do from the screen your in swipe up from the bottom of your tablet, this is normally where you can create new records and change views, for example.

tabletscreen

Type of application – There is not a web browser version of the tablet app, it’s either you access it via your browser and you get the default app (however remember the navigation is large now and quite easy to use on a tablet) or you access it via the application that you downloaded from the store to get the real tablet experience.

Overview_Tablet

The Tablet application when you first open it (from a free trial)

 

mobile1

Enabling the entity for CRM for Phones & Tablets via the Entity Settings

 

Enable your entities for tablets by going to the entity and selecting ‘Enable for Tablets’

Consideration for standard entities and permissions – The User entity is one of the read only entities on the tablet application, see a full list here. This does not have any negative implications, especially considering the interesting point mentioned below about being able to manually calculate rollup fields still. However this should be taken into consideration and one of the downsides of using an existing entity in an XRM solution.

User_record_tablet_RO

The User entity form on the Tablet Application – You can see by the large padlock in the bottom left corner this is read only

Screenshot (18)

You can click associated entities, ‘Requests’ from the User record, but there is no ‘New’ option

 

Global search is not new to Dynamics, it was originally included in the tablet app, and also Scott Durow posted a solution on how to create a (very) similar experience here using SparkleXRM before it was added into CRM 2015 on the top right of the navigation bar. The Global Search allows you to globally search your application on your 10 selected entities (see a previous post here on specifically how to change them) so remember to configure them based for your main application as well as tablet users.

Making your entities accessible via the SiteMap – I did not edit my sitemap to include ‘Requests’ as they were available from the ‘Related’ entities in the web application, however the tablet access won’t allow me to add Requests via the User record with it being read only (see the screenshot above, which is requests accessed via the User entity). This means I’ll need to edit the sitemap to add a place for Requests. Unless your entity is enabled for tablets and also has a specific area of the sitemap e.g. under ‘Sales’ then it will not appear in the tablet app. It ‘flattens’ the navigation so does not include groupings and also does not repeat any entities, which is import for order considerations.  I used the SiteMapEditor from XRMToolBox (which I’ve mentioned in a previous post) to just add a new section to the sitemap. For this specific example I’ve added both Requests and Users to show you the difference – the User entity is read only as mentioned above and noted by the large padlock on the screen (see screenshot below) and you can access existing Requests from it however not make any new ones.

Edited_sitemap

The Sitemap in the Tablet application when added ‘Requests’ and ‘Users’ to the sitemap in the web application

Sitemap_XRMToolBox

Editing the sitemap using the XRMToolbox sitemapeditor tool

 

Screenshot (20)

The Request entity accessed via the sitemap – you can see I can now add a ‘New’ record

Screenshot (21)

The blank entity record for Request

 

You can see the Requests and User entity appear at the bottom of the sitemap as they appear last on my sitemap. On the User record and go to the associated Requests, if you open the menu bar you’ll notice there is no ‘new’ function here, so this seems only good for visibility purposes. On the User record you will notice the option to recalculate the rollup field manually on the user record! Awesome! Keep the ‘User’ entity on the sitemap if you want your users to be able to see contact cards and manually rollup their holiday fields*. It’s important though that I’ve just gone and edited the sitemap for the tablet with no consideration for the web application, any changes you make you do need to consider the affects on all three applications, this is discussed in the Testing section below. An alternative to changing the sitemap could be to create a Dashboard with Requests and/or make this available via the app. (see ‘Configure your Dashboards’ below), this could alleviate any headache on cross application sitemap issues.

screenshot(19)

The option to re-calculate the rollup field on the Tablet application

 

Configure Default Public Views – The primary use case of our XRM Application is users being able to submit Requests for holiday, so we need to be able to make it possible for users to create new Requests. For this to happen we need to make the Requests available via the sitemap in the previous step. Navigating here from the Site Map takes us to the ‘Active Requests’ which is the Default public view, changing the default public view via the settings, solution and the views via the entity will only change this in the mobile app. You’ll notice the ‘New’ functionality at the bottom, selecting this creates a new Request.

DefaultPublicView

Changing the default public view in the Solution entity area

 

 

Check Business Rules – Scope of the Business Rules are checked and need to ensure they are on the ‘Entity’ level for the ones where they are executed upon creation as they are the only ones executed server side. Rule of thumb, if you need a Business rule upon Create, then execute it on the ‘Entity’ level, if you need them on Loading or Updating only then all forms or a specific form will be enough. This should be considered at creating the application and not just looking for when to take it mobile.

Screenshot (26)

The error message in our Business Rule is executing perfectly

 

Configure your Dashboards – You will need to enable your dashboards for use for ‘CRM For Tablets’ by editing them, changing their properties and checking the tickbox. The administrator would need to do these for any system dashboards that have been created. A handy tool is you can also ‘Pin to Home’ and ‘Pin to Start’ so a certain dashboard can be your home screen, similar to how the web application works in that the specific section of the sitemap is the ‘Home’ section, and you can pin multiple dashboards to your home screen so you can just click the Windows 8 Tile it creates and it launches the application and this specific dashboard straight away. A similar feature is available for setup using the web application also.

The XRM Solution functionality is now ready to use on tablets! A user can submit a request, view the user record, and even manually rollup if they want to. You’ll notice the real time workflows still do their job of creating the Request ID for you without any further config.

DashboardConfigTablets

Enabling your dashboard through the ‘Properties’ of that Dashboard to be ‘Enabled for Tablets’ via the web application

Screenshot (29)

Adding Tiles on Windows 8 to Dashboards to the CRM for Tablets application

Screenshot (28)

Accessing my Dashboard via the CRM for Tablets App now it has been activated

 

 

Mobile Application Checklist

Type of application – The Mobile app is a little different – there is actually two versions with a few differences and little nuances that is helpful to be aware of, especially where you may get UAT issues and a user is looking at the app in a different way than you are. You can access your CRM Online (or On Premise IFD) via your mobile browser, and it will change to the mobile application, or you can access it via the actual mobile application downloaded via the store specific to your mobile OS. When comparing the two, they look slightly different and from this, you should know which application you are on (if you didn’t already!) –

mobilecompare

The differences between the Application and Browser Mobile versions

 

Enable the Request entity for CRM for Phones – the User entity should be enabled by default. You do not need to enable the Auto Requests/Definition for phones as we won’t be actively creating Request ID’s on the phone the real time workflow will still handle this.

NormalAppImage(3)

Mobile Application with the Requests entity enabled for CRM for Phones appears automatically in the Sitemap with no config

NormalAppImage(8)

Empty Request form for CRM for Mobiles

 

Consideration for business processes – Our XRM Application will work on mobiles, albiet due to our reliance on rollup fields which are calculated every hour, it means we will have to wait for the user record to update every hour as don’t have the ability to manually refresh (screenshot) like we do on the web application & tablet app. It is useful to know so users don’t wonder why their records are not immediately updating, however the purpose of the application is to submit requests, not necessarily check up on your user record every time you do so. The user will be able to see the requests they have made on the Mobile application. We can access rollup fields using plugins and force them to calculate however it would defer the whole point of an XRM Solution not using code,  a client might not have the budget, or the client might want to be able to maintain it through the UI and their own control, these are all valid reasons not to use a plugin and a difference to be aware of.

NormalAppImage(6)

The User entity is not Read Only on mobiles but a large part is – our calculated and rollup fields are however which means we have to wait for the hour default time

 

Sitemap Navigation – The User entity is not read only in the mobile app, it is enabled by default, however it does not show related entities, so we can’t create a Request from the ‘User’ record (similar to how you can’t do this in the tablet app either). All you need to do to have your entity appear on the sitemap in the mobile application is to enable these for CRM for Phones and it will appear in the main navigation automatically (you don’t have to edit the sitemap using an editor or through the xml).

Cut Down Forms – The fields in the mobile application can be considerably smaller, the main reason being that fields with no value (null or empty) will not display before selecting edit. If you change the fields and add some data in them you’ll see they will become visible in the read only state.

NormalAppImage(11)

The ‘Managers Signed’ and ‘Finance Signed’ fields are not on the form as they are technically empty

Formvisibility

Manager Signed and Finance Signed now appearing on the form

 

Being aware of notable Bug/UI Issues – In the downloaded application when you click lookups, it is worth noting that on some forms (I’ve experienced this with the User entity) that when I click a lookup nothing happens. What does happen is the lookup flip out box actually appears higher in my screen for me to select the record from the list, so if I click a lookup I need to scroll to the top of the record I’m on to find the flip out box to select it. This is slightly annoying, especially as you may think it’s not working.

NormalAppImage(9)

Lookup for the ‘User’ is all the way up near the top of the screen

 

Check Business Rules – The same rules apply as discussed above regarding server and client side, check they still work on your mobile

NormalAppImage(1)

Business Rule is working on the Mobile application also

 

 

Configure your views to display the optimal information – you might have configured them for the web application, but may not have released the mobile application takes the first two fields in that view on forms, so these may need reconfiguring. (screenshot).

NormalAppImage(7)

The View here has the Request ID and the No of Working Days Requested in the View

firsttwofields_mobile

You will notice these are the first two fields in the View Column List – change these to change the view in the mobile application

 

It is ready to use! A user can open up the application, create a request and submit the amount of days they want. CRM will rollup the figure every hour which will then update the calculated field for users to view.

Testing & Other considerations

Even more important across all three applications as you may have noticed that the mobile and the tablet checklist is not the same. An example is you have to configure the sitemap for the tablet application and not for the mobile application, but in doing so you’ve affected the web application (remember you can make a dashboard instead). For these reasons, ensure you do some testing, firstly on your browser simulations by changing the URL of your page to have a /m after it for the mobile application, and then on the specific applications themselves.

I would recommend mapping out the business process in use cases and flow charts for each application if there is even slight differences. It really doesn’t take that long to put together a Visio diagram and it will really help users know their way around each application especially when they first start using it, ultimately assisting with user adoption. You can see in this (relatively small) XRM Application that there is a slight deviation from the process we originally set out in the web application so imagine in a larger scale application and how much deviation might have to be taken for the user’s needs to be met per application.

*Form Order or Security Roles didn’t come into this post that much however they are still very important points to consider when looking at mobile distribution of your XRM Application, so they will be covered in followup posts to further expand on this area.

I hope this begins to demystify the mobile and tablet Microsoft Dynamics CRM Applications! Any questions or comments please post them below.