Well today is a day of announcements, and what a day it was to be a Dynamics 365 User, Partner or ISV.
Microsoft have made a few (major) announcements with regards to their Dynamics 365 platform as a whole and there ultimately will be a few posts on this by various members of the Dynamics 365 Community over the next few weeks.
I will briefly summarise these points, Microsoft have announced the Dynamics 365 Spring Release which includes some new functionality/additions and changes to the Dynamics 365 Business Application suite.
The Dynamics 365 Admin Center has also had a small update to accommodate and manage these changes as described in the following Dynamics 365 Blog.
So there is already a lot to digest, consume, collect thoughts and finally discuss (which I will do in a future article or two!) after today’s announcements. But another small announcement also snuck in…
Under the Radar
Microsoft also announced that the Dynamics 365 App for Outlook V9.0 has finally come out of Preview (I have not yet got access to an environment the new version yet).
This means that any Organisations on V9.0 will be able to use the new version of the App for Outlook (assuming they meet the existing requirements and are using Server Side Synchronisation) and will not have to go through the additional steps of enabling the preview.
Microsoft have added a few new useful features, such as the direct link to View the email in Dynamics 365, Pinning the App for Outlook pane and Search!
Turns to (sorry its a bad picture!):
I previously wrote a few articles regarding the App for Outlook and highlighting some of the new features and also how to configure the Preview version. I will not go into these details again as the articles can be found here:
Back in January, Microsoft made an announcement regarding the “Continued support of the Outlook Add-in” (Dynamics 365 for Outlook) which was due to be replaced by the Dynamics 365 App for Outlook. This decision was made after taking on-board the response from the Dynamics 365 Community and Microsoft’s customers who rely on the Outlook client heavily as part of their interaction with Dynamics 365.
Microsoft have stated that they are going to continue to invest in the Outlook Client to improve its performance and stability, but will not be adding an new features. This however, did raise the following question – what is next for the App for Outlook?
Unified User Interface (UUI)
The App for Outlook is based on the UUI, which is the new interface for Dynamics 365 released for version 9 and is the future of the platform (well except now for PowerApps and CDS V2!). Microsoft are working hard at making this the default interface to eventually replace our beloved web client (which also will mean the end of the Outlook Client as they share a common rendering engine), the un-deprecation announcement means that this is someway off yet.
The functionality of the App for Outlook will be brought in-line with the Outlook Client (i.e. Task Synchronisation/Tracking); Organisations currently have to choose between the functionality that the Outlook Client provides vs the compatibility of multiple devices that the App for Outlook supports. Bringing the features in-line will hopefully eliminate that decision (for Exchange customers) and the App for Outlook will become the preferred method (as Microsoft will tell you now!).
I will be giving my two cents regarding the other announcements over the coming weeks!
My previous blog discussed the use of Staging Databases as part of integration design and some tips and pointers whilst building a staging database (if you decide to use one that is).
My background with data integration is using either out of the box/free tools or 3rd party data integration software (like Scribe or KingswaySoft) and the methods for designing and building data integration have evolved over time. This blog will detail the best practices when dealing with performance issues that I have encountered over the years.
You can apply some (if not all) of these principles for bespoke data integration tools, such as:
Utilising a Service Bus (like Azure for integration messaging)
This will be my final* post when discussing best practices with data integration, most of which can be applied when using any tool to complete the integration.
*Star Wars did not end with a trilogy.
Part 3 : Performance Issues and Improving Performance
Integrating with Dynamics 365 can be a painful learning curve, some of the issues (that I would see as performance related) I have encountered are:
Understand of Entity Relationships (I mean who loves integrating with the Activity and Pointer Entities??) which have lead to poor profile design operations being completed by the integration.
Data import speed (e.g. records per second or records/second) slowing over time.
Network Latency/Connection errors which can arise at any time during the integration.
SQL Timeouts due to high load/queries on the D365 database
Error exceptions such plugins/workflow failing due to lack of resource or Dynamics 365 providing us with as little detail as possible
Additionally, big factor to consider with data integrations and loading data directly into Dynamics 365 is that this can only be achieved via two supported methods:
Directly through the Dynamics 365 interface, manually entering though forms, bulk editing or uploading a file using the out of the box import tool.
Via the API using one of the many free, 3rd party or custom tools available which connect directly to one of the Dynamics 365 endpoints.
There is no supported method for loading data directly into the Dynamics 365 database, and if anyone asks you to do this, just say NO. So even if you are using a Staging DB no SQL – SQL transfers are NOT allowed.
With Dynamics 365 Online, Microsoft have protected customers by this method of tomfoolery by restricting access (or even visibility) to the Dynamics 365 Database!
All Dynamics 365 data integrations must be made through the API, which means they:
Adhere to the Security Model of the User connecting to Dynamics and performing data load operations via their Security Roles.
Trigger any system events or custom automation (bespoke) when record operations occur (e.g. create, update, delete etc.), such as:
createdon is populated
Back-end relationships are created in the database with other records in the system
When records are created, CRM populates the createdby, owner and so on.
Caching of data/sharing of records stored to the PoA table.
And all additional other magical things system operations Dynamics 365 completes (using the Force!) (such as creating an Audit logs trail etc.).
Considering the above items, we can see:
Firstly why loading data has to be (and can only be) loaded through the API.
Why performance maybe slowed by the Dynamics 365 and flowing through the application Layer to the database layer.
Whilst investigating why performance is being impacted, it also makes sense that we investigate ways of improving the performance of data integrations with the aim of improving:
Data load times and record/second.
The quality and reliability of you integrations
I will walk though a common data load scenario which will highlight a few of the performance issues are listed above and are usually encountered when completing a data migration to Dynamics 365.
I will then review the migration and make suggestions/ list my best practices on how to overcome or help mitigate these issues.
Sales Load Example
For this example, I will walk through a very basic scenario of importing data without using any special tips or best practices; this also assumes that the the data integration tool is importing 1 record at a time (discussed later on). This is a direct source to target data import and all values are made up for the purposes of this example.
If you have the requirement to load a medium size data set (e.g. the last 5 years worth of data) for a customer, and say:
12,500 Opportunity Products
Dynamics 365 Online data migration from a data source.
We will use the example Sales load highlighted in my first blog, the load order would be as follows:
Opportunity with grouped Opportunity Products
The loading of the Account data into Dynamics 365 will be relatively painless; it is a simple profile to just perform a Create operation into the CRM database. The Account data set is relatively small and this will probably complete within about 20-25 mins.
When measuring import speed, you will probably hear people talking about records/second (which a 3rd party tool will calculate for you). The average Account import speed here is about 10-15 records/second.
The next step is to load the Contact data into Dynamics 365, this profile is slightly more complicated in the fact that we have to also search for an existing Account to firstly set as the Parent Account ID and also update it with the Primary Contact value.
So instead of the one load operation to Dynamics 365, we have 3 operations with each operation requiring round trips to and from Dynamics 365 to the data integration tool:
Search and Update (Account and Contact)
Because of the additional work the profile has to do, the import speed may go down to an average of 3-4 records/second as the profile is having to do more work (roughly 3 times). This will take approximately 7 hours to import 100,000 Contact records.
This process is actually grouping and loading Opportunities and child Opportunity Product records together and loading these in the same data profile and contains 4 primary operations:
Create (Opportunity Product)
With the added complexity of grouping related data together (Opportunity and Opportunity Products) at the source, the profile may only achieve an average maximum of 1-2 records/second; with a maximum of 6000 rows the load time will be around 50 minutes.
Reviewing the Sale Process load example it can seen that increasing the complexity of a data profile can reduce the performance of the import speed.
For low-volume data loads, the time differences can be in minutes or hours which do not impact project timelines too much.
But, consider the impact to projects where the data sets contain millions of rows (i.e. high-volume); the potential increase in project timelines can be calculated in either days or weeks which your customers will not be happy with.
Identifying performance gains will be critical in these scenarios to reduce the time it takes to integrate the data.
So, how can we go about ways of improving data integration performance?
Environment Optimisation – manipulating the environments around the data such as:
Server Specs (On Premise only)
Data Profile Optimisation – breaking down the steps with your data profiles.
Matching Optimisation – increasing the efficiency when matching to records in Dynamics 365.
Record Ownership – assigning record owners in Dynamics 365.
Record Status – Saving your record statuses until last.
There will be different environments for every single data integration, and there will be different things you can try to help improve performance without touching the data integration itself. The changes could be either hardware (e.g. increase Server Memory) or software configuration (e.g. creating a database index) optimisations.
So lets look at the environmental changes we can complete to increase performance when integrating data with Dynamics 365 – first we can split out the environments as follows:
Source – You may have one or more source systems if merging from multiple systems; if you have a staging database this will be your source system for your data profiles when loading data into Dynamics 365.
Integration Tool Resource – this maybe under your control (i.e. On-premise server)
Transit – Network connection between Source, Target and the Integration Tool
Target – Dynamics 365 (Online or On Premise).
I will use the Staging Database approach with data integrations to provide the context of the environment, if using a file then there is not too much you can do except clear down erroneous rows or the 63000 extra blank rows that Excel sometimes like to add.
So with Staging Databases, I will make the assumption that this is a SQL database (but same tips will apply to additional database types like MySQL.
Firstly I recommend you look standard best practices for optimising a database; I will list out a few of the key ones that you can actually perform yourself.
Create Useful Indexes.
Shrinking the database – often (if using Full Recovery mode).
Keep on top of Database maintenance plans.
Make sure the following routines do not interrupt/occur when your data integration is under heavy load as this will negatively impact the read speed and queries being executed against tables with the potential of generating SQL Timeouts:
The following tasks may require an Customer System Administrator to complete:
Limit your SQL Instance Memory to 1/2 or 3/4 of the SQL Server the instance is located on, leaving the rest available for the Operating System to use.
Log Files on separate hard drives
Increase the SQL Server allocated memory (to enable the above!
Integration Tool Resource
Some integration tools (like Scribe Insight) require their own Server with its own set of resources (and SQL database); I recommend using the following as a guide when choosing a location for your data integration tool:
Take the recommended System Requirements, and then double them.
For bespoke solutions e.g. console apps or web services, make sure they have:
Decent connection to Dynamics 365.
Adequate memory and processing power to function under extremely high load.
A Service Account with appropriate security privileges and access to Dynamics 365.
If these are hosted in Azure and connecting to Dynamics 365 Online, how about moving to the same data center as where your Dynamics 365 instance is located? This will reduce network latency by reducing the number of connections it needs to make to Dynamics 365 via other servers.
For all tools and bespoke solutions console apps or web services – make sure they have a decent connection to Dynamics 365 (as stated above).
Ensure that you are using a secure and encrypted HTTPS connection (applies to On Premise only).
Make sure all IP ranges have been authorised through your Firewall for Dynamics 365
Loading data into Dynamics 365 can be affected by any number of items once the connection to D365 has been established. There are several tips I recommend completing whilst loading data into Dynamics 365:
Disable any automation such as Workflows and Plugin or SLA which maybe triggered on import create/update.
Turn off Email Synchronisation (just in case any get created and sent out).
Postpone some of the out of the box internal maintenance schedules in Dynamics 365 (e.g. bulk deletion tasks).
For On-Premise deployments, standard Database practices should be completed regularly.
Add more resources to the CRM and SQL servers, and split out the Front and Back End server roles onto different Servers with load balancing.
Data Profile Optimisation
We have looked at my recommended best practices from an environmental point of view, next we can look at tweaking the way your data profiles operate and suggesting improvements in logic.
Profile Load Order
The first item to think about is your profile load order, each data integration will require a profile order where the data should be ordered based on the required data to create that record type. The following diagram shows an example scenario for a typical data migration.
The decision could be made to either start with Leads or start with the Product Catalog (Products and Price Lists).
My best practices when planning a data integration and the profiles ordering logic are:
Understanding the essential “must-have” data for production go-live and build a import plan accordingly.
Identifying independent data sets and/or configuration data and focusing on these areas first unless it is not required for go -live or flagged as “nice to have”.
Determining your key data sets which are prerequisites for other data sets (e.g. Accounts are required before you can import Opportunities or Cases).
Import smaller data-sets first for quick wins; if you encounter issues with a larger load and are required to be restarted/fixed then at least you have got some data in and you can concentrate of fixing the larger data-set.
Finish with Activities/Notes and Attachments; these are often the most complicated and difficult tasks to complete; Activities can also be related to any of the proceeding data (e.g. via the Regarding field) and so I will tackle the hardest items until last. Also – Historic Activities are most likely never going to change; these could also be imported after (not part of any critical path) production go-live.
When querying source data, only select the exact columns you need to process as part of your data integration. Any additional Columns queried, but are not used become a waste of resource and can impact the performance of data profiles.
Instead of the below query which returns all Columns.
SELECT * FROM CUSTOMER
WHERE [STATUS] = ‘Active’
Populating Lookup fields often requires some element of validation to ensure that the record GUID exists; e.g:
Profile will first check to see if the record exists
Retrieves the record GUID
Sets the GUID in the create/update operation.
This means that for every lookup value that is set requires as part of the data integration, an extra query to and from Dynamics 365 is required before the Create/Update operation would occur. This will slow down the time it takes to complete the transaction for this row (e.g. the record/second would decrease).
On the Case Entity, you may have several lookup GUIDs to query before the Case can be created:
If we had these GUIDS before we started the import (as we should have imported the prerequisite data beforehand), then we could populate these fields without having to perform the additional query.
This would reduce the number of steps the profile has to complete to just a single Create Case step and improve the performance of data integration import speed (records/second).
For smaller data-sets, this may not be required as the data does not take much time to load; but for the larger data-sets we can see that improvements to import speed can have a positive impact on the total time it takes to load the entire data set.
To record the GUIDS of the pre-requisite data (especially configuration/Account/Contact data) I will always write back to the source data row in my staging database with the record GUID in the original profile. Or, I will build a separate profile which query Dynamics 365 (as the source) and targets the staging database. This will literally just write the GUID back to the Staging database source row.
So back to my Case import example, assuming I had captured the record GUIDS of each lookup, I could either:
Join to the Account,Contact and Product Tables to include the GUID columns in my Case query.
Perform a simple SQL Update Script to populate these values (this will take seconds).
Larger Volume Data-sets
Identify your largest data sets, some of these may be simple but some of them maybe complex. The aim is to improve the import speed (record/second) and the larger data-sets will gain the most from performance improvements.
The downside is, importing large volumes of data will eventually slow down table performance in Dynamics 365, which also will have a negative effect when trying to match to records as part of data profiles.
Reduce the number of steps in the profile by completing additional ETL transformations on the Staging Database (if available) – like pre-populating lookup fields; aim for straight inserts or straight update.
For simple – high volume profiles, many tools (even bespoke Console Apps/Web Services_ can take advantage of the Bulk methods (ExecuteMultiple) provided by Dynamics 365 where you can submit data in blocks as part of a single transaction. These are designed to increase the throughput of your data to Dynamics 365.
Nearly all data integrations will involve some sort of matching criteria, whether this is to return related record ID’s to populate lookup fields on import or when matching for either create new or update existing records.
Matching to records will often involve matching on key fields (in most cases a single field or key, in others the matching criteria may involve multiple field values.
Single key matching example – matching to Orders:
OrderNumber exact match
Multiple key matching example – matching to Contacts:
First Name AND
Last Name AND
Email Address AND
Postcode all exact matches
Whilst matching to these values may be required and cannot be changed. we can actually create indexes on these columns quite easily. In Dynamics 365, you can directly add these to the Quick Find View – Find Columns for that Entity; Dynamic 365 will create a database index for you automatically, this is extremely useful for Online environments where you can directly affect the database without touching it.
Additionally – it may be useful to also create indexes on the source columns used for matching over larger data-sets.
Where unique records are required to be matched, it may be worth considering creating an Alternate Key in Dynamics 365. Ben Hosking has written a very good article on alternate keys here. This will also create an index in the CRM database which improves lookup times.
Assigning records to User or Team can take a while even through the web interface, and this may be additionally impacted by cascading relationships to the records children (if applicable) where is child is also assigned to the User or Team. So this may have a negative impact on the data import speed
Where the requirement for records to be have their ownership during a data migration/integration, I considered it best practice on larger data sets or records where cascading relationship exists (e.g. Accounts and Opportunities) to either:
Recommended – Split out the record assignment into a completely separate profile after the data has been integrated with Dynamics 365. This will increase the performance of data integration initially creating or updating the record; the Assign action can then be completed post load.
Or have an additional relationship to the User Entity (i.e. Assign Owner), populate that during the migration and then have Workflow post Migration/Integration set the Owner to that of the Assign Owner field.
Tip: Ensure Users:
Have been created
Assigned the correct Product License (if Online)
Security Roles have been assigned which allows them to own the record type you are integrating with.
Completing Activities or setting record Statuses can have the same impact that assigning record ownership can have (e.g. cascade behavior). Also, depending on when the profile sets the status, further updates cannot (should not be in most scenarios) be made to those records through the data integration; especially with Activities – you will receive a hard Dynamics 365 error.
So my recommended approach is to consider having a separate record status profile as this will increase the performance of data integration initially creating or updating the record; then a profile to set the record Status executed post load (assuming no further record updates are required).
This completes the final blog*: Performance Best Practices blog for the data integration series, I hope you can start incorporating some of these principles into your data integration designs.
Thanks for reading,
*I lied, there is another post to come with more best practices!
Back in June (2017 for those who read this in the new year), I wrote a series of blogs regarding the new Unified User Interface which was announced ‘July Release for Dynamics 365’ (aka V9.0). The series introduced the readers to set of functionality being released as part (or alongside) the new UUI:
We are now in a time where V9.0 has been available for new Dynamics 365 instances (i.e. trials) for a period of time but existing customers could not yet upgrade. It was announced (here) that the customer driven updates (CDU) will shortly be arriving for existing customers (starting in Jan 2018).
To test – or to not test, that is the question
I have been part of a team that has been testing the functionality delivered with the new UUI and the impacts that it would have on our customers.
The testing was split out into the following categories:
App for Outlook
Tablet/Phone Mobile Client
Mobile Web Client (not the “web refresh”)
We decided to share this content with the wider community to help you advise your customers to make the right decision when it comes to scheduling the upgrade and to make you aware of items that may or may not need to be addressed when the upgrade is ready.
My next set of blogs will (re)-introduce to Mobile Client(s) offered with Dynamics 365 (V9.0) and the UUI.
I will aim to cover the following topics:
Why use the mobile apps?
What mobile apps and types are available?
How do you get the mobile apps and what are the prerequisites?
Installing the app
Configuring Dynamics 365 Apps for mobile use
Custom Controls with the new UUI
Factors to consider when customising
Offline Capability (as you know, the App for Outlook cannot do this at present!)
I have been using the mobile apps for Dynamics 365 since CRM 2013 when they first released the MOCA framework with the mobile apps.
Before that, I had worked on projects that used a third party addon called CWR as the mobile offering (which was a direct competitor of the more widely known Resco) as these where the only true mobile solutions available for CRM 2011 that allowed Users to work with CRM data on their mobile devices (and offline).
Over the last 7 years or so, I have seen the mobile platform evolve from the basic Mobile express forms to the current V8 offerings and have implemented the mobile app in some form in nearly all versions of Dynamics since 2011; I could not have done so with out reference guides/manuals/blogs that have been readily available.
Why should you implement a mobile application for CRM?
Technology is evolving at an ever alarming rate – people are also more attached to their mobile devices (such as Tablets or Smartphones) as they go about their day to day activities. Some of these devices are even replacing a lot of tasks that would otherwise be completed on a computer or laptop.
Dynamics 365 is one of these applications that Microsoft has expanded its mobile offering/functionality and now is the one of the primary focuses of Dynamics moving forward with newer versions of CRM. The UUI is prime example where Microsoft are bridging the functionality gap between mobile and the traditional web client interface and introducing a common interface to display CRM data to users across multiple devices in a uniform way.
The request for mobile access is just going to grow and grow and employees will ultimately come to expect an “App for that” (as there is for literally everything else).
Some of the benefits to users are:
Access to CRM data when they are out and about i.e. Sales Team can pull up relevant information about the Opportunity they are meeting the client with
Users can update their meeting notes, create appointments on the fly
Immediate access to relevant dashboard to show key data on their phone
Custom controls which are optimised to a device to aid/assist in data entry:
Here we can see to custom controls for the iPad client – a signature capture and a star rating control.
There will always be some mobile requirements from your users to use Dynamics 365 on their mobile devices; Microsoft have a very powerful (and free) solution available for their customers to use and configure to meet these mobile requirements with the mobile app offerings.
That being said – there are different mobile apps available with Dynamics 365 and I will highlight cover this area my next blog (here) – so stay tuned!
Recently, there has been a lot of emphasis around the Dynamics 365 July 2017 or v9.0 as its also known as; Microsoft released the Unified User Interface (or UUI) for Dynamics 365 with this released for new Office 365 tenants. This built upon the design concepts of the MOCA client with the philosophy:
Code once, deploy everywhere.
I have previously written an article regarding the UUI when V9.0 was first announced to the world here:
Fast forward until now – you can finally provision trials with Dynamics 365 V 9.0. A few of my colleagues and I have been putting a lot of effort into testing the new UUI in earnest to try and help with our customers come up with a clear upgrade strategy to upgrade to the next version of Dynamics 365.
Our testing for the UUI has been broken down the testing into the following topics:
My colleague, Chris Huntingford had already written an brilliant introductory blog (link above or here) into our initial findings of the Web UUI, which lists a few “Awesome” features and a few of the issues we have encountered so far which we have shared for all to read.
This article received some really good feedback from the Dynamics Community which highlighted some cool items that we needed to consider or had missed, so thank you!
Additionally – I would like to thank Jason Almeida and Rob Dawson for assisting us on the continued path of testing the UUI!
The “App for Outlook” – a Consultants Story.
So moving on to business – I have been testing out the new App for Outlook on my trial demo environment with two main objectives:
How do we install the preview version of the App for Outlook?
What can we do with the App for Outlook?
This blog will serve as an introduction and will aim to help you understand how the App for Outlook can be deployed and installed (point 1) and a high level overview of what it can and cannot do functionally; my next blog will cover point 2 in more detail.
Firstly, you may be asking yourself – “why are we talking about this when there is the Outlook Client”?
I would like STOP you right there – this article is in reference to the new cloud based App for Outlook addin which was first released with Dynamics 2016; the Outlook Client (installed to the Users machine) has been deprecated (RIP) and will be removed from support at some point in the future.
As part of Microsoft UUI release with Microsoft Dynamics 365 July Release (V9.0) – the App for Outlook is only released in preview; which means:
Dynamics 365 (online), version 9.0 or later only.
Not supported – Microsoft will not provide full product support until General Availability (GA)
Not complete product/functionality
Full details can be found here.
So whilst this is great for the Partner to get their hands dirty and do some testing for Microsoft – for new customers, they would be stuck in a scenario where the recommended email synchronisation method is not actually officially supported by Microsoft yet. They may need to go back to the Outlook Client as an interim solution until support is offered/general availability.
Ok – what do I need to get the App for Outlook running for my Users?
Good question – there are several pre-requisites to get the App for Outlook running, I will provide the basics with the necessary links for these as separately, these can be quite a detailed process to complete.
Switch to server side synchronisation (SSS) for all Email and Activities in your V9.0 instance – reference here.
Have a supported version of Exchange (Exchange 2013, 2016 or Exchange Online).
Have a supported version of Outlook (through Office) (2013/2016/Outlook for iOS/Android/Mac or Outlook on the Web OWA).
Previously, with the Outlook client you were restricted to the following:
Supported versions of Outlook/Exchange (still the case with the App for Outlook).
Installation of the Outlook client on each device you wanted to use (Windows only)
One synchronising client if accessing with multiple devices.
For the App for Outlook, you can use a single installation (addin to your Exchange Mailbox completed at the server level) across a multitude of devices and platforms where you access your mailbox through an supported Outlook App (i.e. Outlook for iOS). You can use the App for Outlook on the following devices:
Outlook on the Web
Outlook for Desktop
What can I do with the App?
There are some major functionality differences between the App for Outlook and the Outlook Client (taken from here):
Dynamics 365 App for Outlook
Dynamics 365 for Outlook
Track and set regarding for email
Track and set regarding for appointments
Track and set regarding for contacts
Track and set regarding for tasks
One click set regarding
Shows recipients’ summary
Shows the regarding record summary in the email/appointment
Works with Outlook on the web
Works with Outlook desktop
Works with Outlook for the Mac
Works with phones
Open and create Microsoft Dynamics 365 record directly
Apply custom forms and business logic
Apply email templates
Apply sales literature
Apply knowledge articles
Ability to monitor emails after sending
Sort, filter, format, group, and categorize views
Create Word mail-merge documents
A lot of people will focus on the negatives – so neither Task synchronisation or Offline ability will be available (with this release) of the App for Outlook.
However – Tasks would synchronise via server side synchronisation as they normally would – you just will not be able to set the regarding or access the CRM fields in Outlook for Tasks.
Whilst you will not have the ability to work offline, you now can with the mobile apps!. The new functionality (in my opinion) far outweighs the functionality missing with the ability to work on the move with your mobile device – though however, this does depend on which device you are using as shown below:
Understanding the above items is crucial when deciding whether the App for Outlook is a good fit for your customers/organisation as it will help identify whether your current Dynamic/Exchange deployment are supported* moving forwards.
As I had previously stated – my next blog will talk about the functionality of the App for Outlook – what’s cool and what’s not so cool!
The below link highlights some already known issues of the App for Outlook – and will be kept up to date by Microsoft.
You can find the second part to this article here.