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!
Welcome back! I am currently revisiting my data integration series where I am highlighting data integration best practices that I have learned since my junior consultant days, these best practices are which I abide by when I am designing and building data migrations/integrations with Dynamics 365.
It took several large Data Migration projects to realise that loading large amount of data from the source data set directly to the target system was not the most practical solution, the size and complexity of the data migration profiles was very inefficient. For data migrations where merging of one or more source data sets was also required, it was clear this should not be completed in CRM and often required numerous clear downs until the logic was correct or post migration clean up activities to remove duplicate data were required. I required a solution that sat in the middle of both the source and target which would have the following properties:
Ability to merge the data sets.
Be a familiar platform which I know and is compatible with the data integration tools I used.
Allow for data transformation to take place before load into CRM.
With discussion with colleagues and reading recommendations from the CRM community, it was clear that a staging area was required. It would have never occurred to me to add another component to a data migration, my thought process regarding data migrations/integrations stemmed around moving data from source to target (with no via option) only.
Location, Location and Location
When I first started out with CRM, most of my projects where On-Premise based; customers had numerous on premise servers (mostly VM’s) but also dedicated SQL instances for various applications they hosted (including CRM).
Additionally, the data integration tools I used where also on premise (i.e. Scribe Insight), so where else better than to host the new Staging database in SQL! CRM is built on top of it, it reports from it and so does Scribe; perfect – a Staging Database.
When I talk about staging databases, I refer to a new database which is independent of any data system I am integrating with. This will be either hosted in an On-Premise Microsoft SQL Server instance or Online in Azure SQL.
Tip if using Azure SQL – locate the Staging Database in the same (or as close to) the data-center/region of your Dynamics 365 instance to reduce the distance the data has to travel.
So, what are Staging Databases?
Staging Databases are used as a temporary storage locations between two (or more systems), they allow integration consultants to:
Merge multiple source (and target) data sets whilst de-duplicating the data.
Perform the standard ETL operations (Extraction of data, Transformation of data and Load of the data into the Staging database tables) so data is in the required format before loading into the target system.
Provide a complete view of all merged and collated data in a single location before it is loaded into the Target (such as row counts, data volumes and size).
Allow loading of transformed data into the target system without impacting on the Source Systems.
Why use them?
Staging Databases should be considered when there is either a large amount of data (high data volume) or multiple data sources need to be merged together and a fair amount of data merging or data transformation is required. Completing these tasks as part of a direct source-target data integration can impact the performance of the integration (and data systems) and data quality of the integrated data sets massively which can be prone to errors and failure.
Performing all the merging and data transformations in the staging database will increase the performance of the data loading into Dynamics 365 (which we all know can take along time); performance will be discussed later on in this series.
Data comes in all shapes, sizes, formats, localisations; throwing this all directly at Dynamics 365 will require significant conversion (e.g. Date Fields, Currencies, related records, Option Set mapping) which will reduce the efficiency of the data load.
Do not under estimate the importance of good quality and timely data, integrations that are very slow and frequently error will never be well received by the customer.
Data Integrations require time and investment, there is importance when designing a good and solid, quality integration. The same applies when designing and planning for Data migrations, these are often under estimated in every project, but these usually lead to the longest delays (time) that a project will experience.
A couple of years ago I attended a Scribe User Conference in Amsterdam, I was talking with one of the European Scribe MVP’s, Martin Buebl, he was discussing his latest data project (which went very well) but coined the phrase “You will never here anyone talk about a good data migration, only bad ones”. But one of the standout reasons (barring his expert knowledge of data integrations and the tool) is that it went very well was that he used a staging database to merge together a few systems (and by a few I mean a lot)!
Not every scenario requires them, for example:
Simple integrations where only one system with a small amount of data is transferred may not warrant the time and investment spent building such an integration. This also may have a Transactional/near real time requirement, where the addition of a staging component may slow down the integration time.
Think about your integration, consider if the design could benefit with a staging database and discuss it with your clients.
Building the Staging Database
Before you can use the staging database, you first need to define the schema of the Tables and Columns required.
When I design an integration which requires a staging database, I try to re-create the schema of the Dynamics 365 Entities and Fields (and data type) inside of the staging database that I will be mapping to. Whilst this may seem overkill and unnecessary to some, there is method to my madness as it actually makes it easier when building up mapping profiles and I find myself rarely having to reach for data mapping document (and this is a future best practice). There is an added bonus if the third party tool has “Auto Map” where similar or identical column names are mapped (Scribe does!).
I also learned how to create (and drop/recreate) database tables with SQL Scripts instead of manually creating these. Re-using scripts between projects can be especially useful for when using the out of the box entities and fields, these will not change and you just need to add the custom columns and datatypes that are bespoke to that customer.
Another benefit to recreating the Dynamics 365 schema in the staging database makes the data mapping profile simpler, you already know the target location and you will be able to reduce the number of target profiles you have (maybe even a single profile!).
Tips when using Staging Databases
Build the tables with a unique Staging Database ID’s which have an index (helps with lookup performance), so you can relate imported data back to source row and will help with Error reporting and row identification if you pass this information to CRM.
Build when you CRM Solution Design (data model and schema) have been completed, signed off and maybe even built so you that have a reference of what the target solution will look like and data mapping can be completed.
Build an Option Set table allowing you to map option set values to target Dynamics 365 Picklist values.
Think about building the error/transaction tables to aid with error reporting and investigation.
Convert the database to Simple Mode (to reduce database white space usage at the beginning).
Backup your Database frequently and immediately after you have finished building (Backup and Restore allows for faster clear downs than dropping all rows/tables).
Build and maintain (rebuild) Indexes across larger tables frequently on key columns that will be searched across (not really required for tables with low volumes of data).
Build useful Views which will join together Tables from a system perspective instead of using a Join in your data queries.
Avoid performing data integrations/ETL profiles during you maintenance jobs on the staging database!
If using an On Premise database, make sure the log files (MDF and LDF) are on separate drives.
Allow more than 4GB Ram!
This concludes my best practices advise around Staging Database best practice and why you may wish to use one, the last article in this series will focus on:
It has been a little over a year and half since my last data integration blog, I had started this blog but never finished it, and now have some time to review and actually finish this series (and to help me prepare for the CRMUG in Reading on March 1st!).
My previous data integration blogs can be found here:
Most of the content in the above posts are still relevant and valid; except Dynamics CRM Online is now Dynamics 365 after the re brand (yes – this was 2016).
I have decided to split out my the content for this topic into several articles, as I was writing the topic I realised that there was a lot to cover; so please be patient!
Replaying back to Part one of this series, I mentioned that Data Integration needed to be defined into the correct terminology, such as Migration, Integration or Replication.
Whilst the term helps define the data integration tools that we can use to meet that scenario, best practices can be applied to all types of data integration to ensure a consistent and uniform approach to all scenarios where integration with Dynamics 365 is required.
Data Integrations Best Practices will help:
Reduce time spent building up successful integrations.
Increase the performance of the integration (highly beneficial with large volume moving data).
Reduce time spent investigating issues and working to a resolution of these issues
Part 1: Error Reporting and Integration Accounts
Types of Error
All types of data integration will at some point cause an error, there are so many working parts to an integration and errors that may arise are:
Source Data – the quality and format maybe incorrect even though the customer the adamant that they have fixed any errors.
String Lengths – too long for the target field.
Decimal/Whole Number data mismatches.
Assigned Owner does not have the correct permissions to own the new record.
Plugins triggering on update and expects a value present.
Target Data/Metadata – a recent change to the system may have changed the metadata of the field that is apart of the integration , the source data no longer maps correctly.
Source or Target availability, the systems have gone offline.
And the list goes on for a whole number of reasons.
The Learning Curve
When I first started learning how to use data integration tools, I often would focus on the core functionality that the tool offered. This would just be to perform the basic operations (such as Read, Create, Update) and to get the sample data to move from A to B.
Any errors that arose, I would ignore and investigate at the end and put it down to my lack of understanding/knowledge of the tool.
In some cases it would take many hours actually figuring what was causing the issue in the first place as there was no meaningful message presented at the outset.
As my exposure to different data migration/integration projects grew over time, if I encountered an error, I would learn new ways (based on the tool I was using) to investigate and identify these errors earlier on in integration picking up hints and tips from online forums and my colleagues. Ultimately, I leaned how to handle and prevent some of these error from ever occurring by building conditional logic and extra validation checks.
When you an encounter an error, there are two actions that need to be completed:
Investigation – The integration is failing and you do not know why – so time will be required to investigate what is causing failure and identifying the error
Resolution – Can you prevent/handle the error as part of your integration or how else will you resolve the error.
If you are using 3rd party data integration tools, error reporting functionality should be provided as standard, and that if used correctly can, be very useful.
Scribe Insight has several tables in its internal database (known as the execution/transaction log) where it stores captured details for every data transaction (row) that it handles, the errors provide some very descriptive detail when an error is encountered (e.g. the length of the value XYZ is greater than the length of field 123). You can also assign messages/output text to Steps/Actions that Scribe takes throughout the DTS package which you can additionally write back to your source data to help you read the errors in more meaningful language to you.
Additionally Scribe has some out of the box SQL SSRS reports which you can view from the application which can provide useful statistics on the import and help you group types of errors or data integration failures.
Whilst KingswaySoft is built on top of SSIS, this can output failed rows along with the errors whilst also parsing some very good error details and description to the failed rows (along with additional row information). This can be outputted to custom Excel spreadsheets and tables or a separate Error Reporting Database and Tables (my preference as I have SQL scripts to recreate tables and schema for me!), then it is just a case of mapping these rows to the respective columns. This will allow you to view these errors in a meaningful way and help you diagnose the issues quicker.
With both tools, you could even have error logging Entities inside of Dynamics 365.
When either tool encounters an error, you can write the record of the transaction to Dynamics 365 for visibility to Users in the Application (unless CRM down is the issue!) and the Users can start the investigation.
Whilst you will not be able to prevent some or all of the data related errors (i.e. the data is the customers and they should be resolving the data issues or instructing you what to do) you can prevent some of the errors you encounter.
Both packages allow you to determine what happens to each transaction if the tool encounters an error (data or system generated) – i.e. error output rows. Whilst the default action is to record these errors into your error capture area and move onto the next row, you could re-process the data with another set of steps the tool must take to try and correct itself.
For example, if you have an integration which imports Accounts, Contacts, Opportunities and Products, and each of these processes are happening at different times such as the Sales Process Load below. What happens if a required record (such as Customer) does not exist if you are loading opportunities? If the Opportunity is created without the Customer value present (a required field), this will cause an error.
Q. How could this scenario be handled as part of the integration?
A. By conditionally checking for the customer record to exist before you set it, instead of making the assumption that this will exist will prevent an error for being generated. This row could then be re-directed for a second attempt in the next Opportunity data load or wait a few minutes for the Account data load to catch up (Send to Retry).
You will not be able to cater for every scenario, additional checks do come with added performance hits which I discuss later on in a follow up article discussing performance and are not always necessary.
Be proactive and think about these scenarios, build the data load logic to handle and prevent these types of errors from occuring.
Learn how to use the error functionality of these tools as part of using the product, they will save you invaluable time further on down the road and allow you to identify the root cause quicker.
Report the Error in a meaningful format
Handling of errors or scenarios to prevent errors
Some of the free tools, such as the OOB import wizard unfortunately do not always present us with a nice detailed error or have the ability to retry, they may even just give us a code! So when choosing a data integration tool, think about the requirement for error handling and whether investing in a 3rd party tool would outweigh the time spent investigating potential errors with Free tools (a consultant spending a day or two on an error may cost the same as a 3rd party tool!).
The use of service accounts with Dynamics 365 is nothing new these days and is common practice with On Premise Dynamics 365 (CRM) installations to run CRM Services or external web services that connect to Dynamic 365 programmatically.
When discussing service accounts with a data integration context, always consider the size and complexity of the integration/migration and whether this would offer real value or not.
For small scale one-off data migrations or using the OOB import Wizard/Configuration Migration Utility tool , service accounts are generally not required; and for the example of the OOB Import Wizard – cannot be used as they cannot be used to access features through the user interface.
For larger data migrations or data integrations (where data will be integrated with one or more external systems over a period of time), a service account should be considered as best practice.
Service Accounts provide:
Tractability of integration: it will be easier to identify data that has been modified by an Service Account especially with Auditing and the Createdon/ModifiedOn fields in Dynamics 365.
Full control of which applications use the service account and can reduce the number of concurrent connections used to the Dynamics 365 server at any one time as to not interfere with connection timeouts
No Front End access, this will stop any one with the credentials from logging into the application and using the product with the Web Client.
Service Account in Dynamics 365 Online are know as Non Interactive users, you are allowed to setup 5 Non interactive user accounts per Office 365 Tenant. I recommend creating these in your first instance so that if you copy the instance, then you will not have to re-configure this User as a non interactive User.
As they are free, there is no reason why you should not use one and are very easy to setup!
Azure AD account (Online Only)
If considering an data integration/migration with Dynamics 365 Online, ask for an account with the default .onmicrosoft.com domain. (e.g. email@example.com). If a company has their on premise AD domain synced with Azure AD and something corrupts/interupts the sync and those Users cannot log into Office 365. The default .onmicrosoft.com would remain unaffected and the data integration would not experience the same issue (unless the source system was affected by the AD issue!!).
Think about the Dynamics Security Role the integration account actually requires to complete its assigned task. At the beginning of a data integration, System Administrator will get over the initial hurdle permission issues (especially in the increase in security requirements are drawn out) and may help reduce the initial build time for the integration. For UAT and Production, the integration account should only require the permissions it actually needs to complete its task.
This would stop this user/integration from being used to update/delete/create other data sets that it was not intended for. Essentially it locks down a potential weak spot in the security architecture.
The account would only see the metadata it requires for the data integration (which would help with metadata refreshes at build level also).
I would generally name an integration account along the lines of “Data-source Integration User” or something that would easily identify the account which is being used to integrate the data-source.
So to summarise the Integration Account:
Think about using a Service Account (or Non Interactive Account) for data integrations.
Use a default .onmicrosoft.com Azure AD account if allowed to. (Online only)
Security Role: Give only the permissions needed to perform the data integration.
Choose a good name!
I have many many for tips, tricks and best practices still to give, such as (not the full list either):
Performance improvements (increase that Rows per Minute counter) and other considerations
Yes – I am a geek, and I apologise for the title, I just could not resist!
I have been working with Dynamics CRM since 2011 (not the product, the year). To some of us, that does not seem like a long time ago – but actually, if my maths is correct, it is a little over 7 and half years!
To me – time has flown by; I have enjoyed every stage in my career and I have not even had a slightest thought regarding a career change. I love working with Dynamics 365, the people around me are excellent and will continue to work with CRM many, many years to come.
Whilst working with Dynamics CRM, I have been given the opportunity to work in a wide variety of project roles; these roles depended on the size, complexity and team of the projects I was a member of. Without regurgitating my CV, here are a few of them (at a very high level):
Support Technician – working on the customer support desk helping to resolve customer support issues.
Junior Consultant – shadowing delivery teams and assisting on basic CRM customisation and documentation.
Data Integration Consultant – designing and building data migration/integration solutions to move data in and out of CRM with external systems using third party integration tools (such as Scribe)
Functional Consultant – gathering user requirements, producing documentation, assisting the CRM solution design and performing a lot of the CRM customisation and configuration duties.
Pre-Sales Consultant- helping build proof of concept solutions and leading demos with potential clients.
To some people, the roles above would not be thought of as being “Technical”, nor do I see myself as a technical consultant. I am a Functional Consultant, but I do have a technical head. This does lead to the question which changes depending on who is asking:
What is the role a Functional Consultant?
Or with personalisation of the question, as a Functional Consultant, what can you do?
The functional aspects of my role
I previously gave a high level overview of a few of project roles that I have undertaken. But if I was to expand out and focus on just the functional role (which is my actual day to day role) and listed out all the tasks that I expect myself to be able to complete (based on my skill set); then I can actually see that there are not just project roles, but there are different aspects to my role which can be split between a project focus or role focus.
My Role aspects are tasks or activities which I complete in addition to my project role to further my understanding and to help improve at being a Functional Consultant for Dynamics 365.
Over the next few sections, I will list out the tasks that I complete (at a high level and split between project and role) and give my own opinion on what I think a functional role should do, but I will not list what you should not do, as that is entirely up to you.
The key to being a good consultant is knowing your strengths and also knowing your weaknesses.
It is important to know your own skill set and doing what you are comfortable with, what you are willing to do and finally any areas you would like to improve.
Sitting down face to face with key business stakeholders and discussing their organisation is a key part of any project, and should be completed at the beginning of any Dynamics 365 implementation (otherwise where do you start??!).
Whilst this is not always an easy task, it takes confidence and experience to ask the right questions upfront, but I have learned that you just need to be yourself and do not shy away from this and keep at it!
Identifying the current and proposed user roles.
Map out the user journeys and their current processes.
Performing gap analysis between current process and Dynamics 365 out of the box, or even suggest ways to help improve the current processes.
Whilst this may fall under the Business Analysis aspect, gathering and documenting user requirements (e.g. by any method such as User/Job Stories or even just a standard list) and consolidating the list into a readable format such as a functional requirements document can be a time consuming task. This is a worthwhile exercise and will help you explain to business what you are expecting to deliver whilst reducing any potential duplicate or conflicting requirements.
Writing documentation, in any role, is apart of the job; whether this is writing:
Solution Design Documents
Functional Requirements Documents
Technical/Bespoke Customisation Specifications
And the list goes on….
Wait a minute, is this not the boring bit of your role? Not in my eyes, producing documentation does not just mean writing lots and lots of text. In fact, writing more and more can drag out the document and put the user off reading the documents and being able to understand what you are delivering.
“They say a picture speaks a 1000 words”, so why not add some great visuals to your documentation? Get creative! I love using Microsoft Visio, I do not write a documents without them. I embed the diagrams I create into my documentation, whether I am creating Entity Relationship Diagrams (ERD) or process flows to highlight the business architecture. Along with simple narratives can be used in place lots and lots of paragraphs trying to explain the same thing, it will be easier on the eye and will aid the audience to visualise your solution.
Setting up Environment
With the rise of Microsoft Dynamics 365 Online, more and more customers are moving to the cloud. Installation of Dynamics CRM used to be one of the main tasks completed by consultants into a customers environment; and if an Internet Facing Deployment was a requirement, then this may have been a bit too technical for some (including myself!).
Most of the projects I have worked on over the last 4-5 years have been online only; which meant the most I have ever had to do was setup an Office 365 tenant and then provision an CRM instance (a lot of customers already have an Office 365 tenant). Microsoft have made provisioning CRM so painless and effortless, I see this as a key task that I would complete.
You do not need to be a Solution Architect to be able architect a solution for a customer. Granted, it does take experience through working on different projects, I will still talk through any of my designs with colleagues to ensure an agreed solution is chosen for the client.
Data modelling and generating the ERD.
Identifying potential solutions to meet requirements through collaboration with the technical teams
Solution Architecture with external systems
CRM Customisation and Configuration
Understanding the full Dynamics 365 functionality provided out of the box is a key requirement for a Functional Consultant. Knowing what is already achievable within the product can help you architect a solution for your customer using whats achievable within the XRM Platform.
These are the items that I enjoy most as a Functional Consultant – hands on with our beloved product, building the solution using basic customisation and configuration of the XRM platform.
The functional role should be the primary resource completing the following implementation tasks:
Creating and customising Entities/Fields
Designing and creating forms with a great user experience with clearly defined and simple layouts
Utilising out of the box business automation (such as Business Process Flows, Business Rules and Workflows) to create business logic.
Building up System Views and Dashboards which provide valuable and meaningful information to the Users.
Defining the Security Model (e.g. Business Units, Security Roles and Teams) and assigning users the correct permissions.
Setting up configuration data and system maintenance routines (i.e. bulk record deletion, Duplicate Detection etc.)
System Settings – Server Side Synchronisation, previews and Dynamics 365 Addon.
Configuring Mobile Applications and App for Outlook
There are many more tasks that need completing, and this is just a short list otherwise it would go on and on!
With CRM V4 and 2011, there were no Business Rules, Business Process Flows or even Synchronous Workflows. The options available where:
Server Side Automation
Custom Workflow Activities
Within Dynamics 365, extending can mean:
Process Flows (Business and Task)
Modular App customisation
These items are before we even talk about building Custom Workflow Activities, Plugins, Actions and Web Services.
Externally – we can also extend Dynamics 365 such as:
Azure Logic Apps
Azure SQL (with Export Service)
Reporting requirements are often a key requirement of an implementation, to present related and meaningful information in a suitable format. I will often perform the following tasks to meet these types of requirement:
Out of the box charts and reports
Create and Update Views
SSRS (Fetch based for Online) using Visual Studio
Power BI Dashboards/Reports
Test what you design and build! Another major aspect of the Functional Consultant; if you have asked the development team to build a piece of bespoke automation such as a Plugin or Workflow Assembly – you should be the first one to test it. Has the acceptance criteria that you have defined (and the customer has agreed) been delivered?
If you do not use automated test tools (such as VSTS test manager*) to help you build test plans and scripts, then often the requirement for writing test scripts for the end users may fall on our laps!
*Test Manager is great for recording your screen navigation and clicks!
A Functional Consultant can drive a key business relationship between the Dynamics Partner and the customer, they are usually face to face with the customer.
There may be a training period just before UAT and also production go-live, and this needs to be delivered. Unless you have dedicated training resource, then usually it will fall to a functional role to provide/lead training sessions for users. This can either be in person onsite, or remote via Web conferencing (where international travel is not practical/an option for instance).
The different training types may include:
Additionally, the focus of the training may not be just on the Dynamics 365 web platform, but the additional interfaces/add-ins such as:
Part of training often involves some element of documentation and producing training deliverable are often required such as:
A consultant should also know that Microsoft have released some great online content for documentation guides, and we should not be re-creating these if Microsoft have already produced something similar!
In future projects, I would like to investigate setting up Learning Path!
For the smaller projects, I would expect solution deployment to be completed the Functional Consultant; on larger projects – there may be external components that require additional technical resource to complete (i.e. Azure Jobs etc.).
Moving solutions between environments will often form part of a deployment strategy between the environments.
The following components will often need to be deployed between environments:
CRM Solutions with export/import and publish functionality.
Moving Configuration data between environments with configuration migration utility tool.
Setting up Business Units, Teams, Queues and Users in each Dynamics 365 Instance and assigning security rules.
The administration overhead of a few of these tasks can be reduced by using different plugins found within the XrmToolBox!
Go Live Support
Delivering a solution does not mean your time on the project has come to an end; the Functional Consultant will usually be on hand to assist users as the system transitions from UAT to go-live. We can guide users through the process correctly and help identify any issues/recreate any bugs not found during UAT.
3rd Party Add-ons
Quite often there are certain requirements which require bespoke customisation; and it is quite often that a 3rd party offer a solution that meets about 80-90% of the requirements.
Over the years I have encountered these scenarios and have actually investigated and implemented some of these solutions e.g. DCP from MSCRM-Addons
Keeping up to date
The Dynamics 365 platform is continuously evolving, recently Microsoft have released V9.0 and have rebuilt the current interface and built us a new one called the Unified User Interface. Whilst this is positive and exciting, it makes life difficult to keep up with the pace! There is so much I want to learn and investigate, and by the time I have gotten around to doing so, Microsoft go and release something new!
As part of my CRM learning over the years, I found the most helpful resource is the Dynamics CRM community, engaging with them has been the most beneficial and rewarding parts of my role. If you have any questions/queries of even encounter issues, then there is always someone there eager to help!
Further, as mentioned above, I like to stay up to date with the latest releases of Dynamics 365 product. I do this by:
Reading community written blogs and MS blogs
Learning about new features and writing blogs on them, this allows me to help make a contribution back to the community!
Attending Events (such as CRM UG) – great for gaining valuable and insightful knowledge whilst also making new connections and having fun!
Dynamics 365 Forums – go to help areas to gain help and advice from your CRM peers!
Collaborating with colleagues
Helping your colleagues leads to great teamwork, do not shy away from this. I aim to be proactive and will help where I can, ultimately they are the first people I turn to if I ever need help or guidance.
Dynamics 365 Certifications
Last but not least – Certifications.
This is something I have slacked on the previous year, but I am aiming to resolve this aspect later on this year!
To aid my learning, I find that using the Dynamics Learning Portal is invaluable. It helps me keep up-to-date with the latest functionality and provides contextual information to help identify scenarios where the functionality can be used to meet customer requirements. It is also a valuable place to follow the exam content which is tested as part of the certification exams.
Whilst I have not listed all the aspects of the functional role, I have highlighted the key items that I complete, as a Functional Consultant for Dynamics 365! Please remember that this is my own opinion and view of a role that I perform every day of the week.
Hello, it has been a few weeks since I posted my last blog relating to the new Mobile Apps for Outlook and the Unified User Interface; you can find my previous article here.
For this post, I will explore the following new areas of functionality that have been provided with the UUI and available on the mobile devices using the new Dynamics 365 Mobile Apps:
Custom Controls and the CCF
Controls for Views
The boring bits
With Dynamics CRM 2016, Microsoft released visual controls for the mobile apps as a preview, these were configured through the form customisations area and by setting individual field properties for each form; link to the YouTube video providing an overview is shown here.
With V9.0, Microsoft released the Custom Control Framework (CCF – not this CCF) which builds upon the earlier release of custom visual controls, these have been slightly updated and refined to work inside of the UUI.
I won’t go through the process of adding Custom Controls to your implementation, the Microsoft documentation is excellent in this regard with the link provided here.
What are Custom Controls? Good Question!
To add bespoke UI functionality to forms, previously Microsoft allowed developers to add i-frames/web resources onto the forms which may display some sort of fancy looking HTML object to enhance the user experience for the customer. The bespoke functionality would have been anything to allow users to visualise or enter data in a quicker and easier method than Dynamics CRM allowed using just out of the box methods, such as:
Visual indicators which where dependent on field values (i.e. like a case priority with a red indicator for the serious tickets requiring urgent attention.
SQL/Fetch XML Reports
Custom Buttons – these may have associated N:N records using a checkbox list rather than manually creating the relationships between two records.
Editable Grids – Before Microsoft blessed us with their version of Editable Grids, this functionality was built by many 3rd parties using HTML web resources.
With custom controls, Microsoft provides a way for users to visualise field data which may contain only text or numbers, by providing a visual/presentable format that is more user friendly allowing the user to consume the data in a format which has meaning. Whilst also designed to provide new visualisations to user, custom controls also provide a new method of data entry which are designed to be used with a Mobile device and Touchscreen interface.
What is the Custom Control Framework (CCF)?
In simple terms, it is an extensible layer that sits on top of Dynamics 365 forms which allows partners and 3rd party vendors a framework with which to build custom control such as visual indicators or custom functionality to enter data. Unfortunately, Microsoft have not yet released the SDK and what we do know is currently under closed preview and NDA. The CCF however, will allow partners a new framework in which to design, build and deploy custom functionality in Dynamics 365 as their own IP.
Where do Custom Controls exist?
Microsoft previously provided us with the new custom controls in CRM 2016 to be used on the Mobile Apps, these were originally configured through the Form Customisations area in Dynamics CRM. This is the same place where you can configure them for the UUI, but they are now visible not just on the mobile apps but also on the web browser for UUI.
With Version 9, there are now additional custom controls available for Views too!
Current Form Custom Controls
The following shows a list of the current Custom Controls which are provided out of the box with V9.0, with a brief description and scenarios these controls may be used.
Field Types: Whole Number, Float, Currency, Decimal
When to use: These are really good for adding in numeric values where a defined range is set, i.e. entering a measurement value in.
Field Types: Single Line of Text
When to use: Autocomplete fields are good when you would like to restrict the options available to the user but allowing them to type them. They are similar to option sets but can be configured using an Entity and a particular field value off the records.
Bar Code Scanner
Field Types: Single Line of Text
When to use: Great where Bar codes are used. If the User is using the Mobile Apps, the Bar code Scanner will ask to use the devices camera to scan the Bar Code and enter the scanned information into Dynamics 365. This may be good when issuing scanned bar-code passes at Events when attendees arrives – as this effectively can provide them access to certain areas at your event with their pass.
Field Types: Whole Number, Float, Currency, Decimal
When to use: I personally use these on calculated fields where an average value is required. You can highlight the range and set low, high and good value indicators on the bullet graph.
Flip – Switch
Field Types: Two Options
When to use: of you enjoy a toggle/flip switch Yes or No (Boolean) option!
Field Types: Single Line of Text, Email, URL, Phone
When to use: Input Masks can be used to create a set format for Users entering data into certain field types. Say if you are entering serial numbers for a particular model or product and they all take the form W-X1X-1234-ABC (i.e. starts with a W, then different combinations of number and letters), you can use a Input Mask Control to validate as the data is entered.
Field Types: Whole Number, Float, Currency, Decimal
When to use: Linear Gauges and Sliders are different Controls which allow users to enter numeric values on a mobile device easier based on a set range.
Field Types: Whole Number, Float, Currency, Decimal
When to use: Linear Sliders and Gauges are different Controls which allow users to enter numeric values on a mobile device easier based on a set range.
Field Types: URL
When to use: Along the with the Website Preview fields, you can provide preview panes to websites or media based on data entered into the URL field configured with these particular custom controls. The screenshot shows a link to Chris Huntingfords CCF video on YouTube!
Field Types: Whole Number, Float, Currency, Decimal
When to use: Number Inputs provide the default method of entry along with the + or – buttons to add or subtract values (in step amounts) from the number entered by the User. Good for keeping to a set level of precision. I have used these for small number ranges where 0.25 increments where required from negative to a positive number range. (i.e. -10.50 to +5.75).
Field Types: Option Set
When to use: The only time you should use this is for an Option Set of 3 or less; or you will not see the additional options! Does not work with Multi-Select Option Sets.
Field Types: Multiple Lines of Text
When to use: These are really good for when you would like to capture the the signature of someone and store these digitally in your Dynamics 365 platform. Say your Service Engineers visit customers to perform onsite services or repairs. When the customer is happy that they have completed the task, they can sign using the pen control and this is saved to the work order/record in Dynamics 365. Chris provides a great video walk through of this field type here.
Field Types: Whole Number, Float, Currency, Decimal
When to use: Great for entering larger range of numbers with larger step amounts.
Field Types: Whole Number
When to use: I can see these being used for gaining feedback back from people (i.e. customers receiving a service) whilst onsite and allowing them to enter data in an informed manner.
Field Types: URL
When to use: Along the with the Media Preview fields, you can provide preview panes to websites or media based on data entered into the URL field configured with these particular custom controls.
So there are quite a few of the Custom Controls available with Dynamics 365, these help improve the way Users can enter data into the standard fields/data types than they could previously. Instead of having to just tap and type, the users can interact with the Control (such as swiping or turning a digital dial) to enter data into Dynamics 365.
Custom Controls available for Views
Custom Controls are not just available to Fields, but Microsoft have also provided us some at the View level (and not just in the UUI); Microsoft first introduced the Editable Grid have extended the custom controls for Views even further with the following options:
Read Only Grid – standard out of the box grid for viewing a list of records.
Editable Grid – recently released with Dynamics 365, one of the most requested features by end users where users can amend records line by line in a list view.
Timeline Control – allows data to be represented in a Timeline format where you can see records in a Timeline view based on when the last action occured (such as created on.
Calendar Control – data can be displayed on a Calendar like Appointments in your Outlook Calendar.
Going back in time to the CRM 2011 days, Microsoft provided Users with guided processes through the use of Dialogs (which have now been deprecated with V9.0). And more recently with Business Process Flows [BPF] (which have evolved over the years).
With V9.0, Microsoft have extended the BPF functionality by introducing Task Flows.
Business Process Flows, Workflows and Dialogs are generally executed in the Context of a record (i.e. when you create a new record the or when you are at the record level, or execute against multiple records in the case of a Workflow). Task Flows can be executed from anywhere in the mobile app by clicking the below icon:
Task Flows are defined against a particular entity in the system, but the User will need to first choose which record they wish to execute the Task Flow against, be this selecting an existing record or creating a new record.
They are useful for providing Users a common set guided of actions or tasks that they would normally undertake.
Unlike Business Process Flows, multiple instances of the same process can be executed against the same record; they are unique to the User – not to the record like for Business Process Flows where a single process instance passes through Stages and Steps to completion.
Neil Parkhurst has written a very good walk through/guide article explaining Task Flows and the differences between them vs Business Process Flows here:
Microsoft provide 3 Task Flows out of the box illustrating different ways in which a Task Flow can be used, these are:
Follow up with an Opportunity
Task Flows allow a User to enter data from different entities in a single form view where data is broken up into section by the labels. This should help reduce the navigation between records that a User would normally undertake to complete these steps which is important for the number of clicks/loading of data when accessing Dynamics 365 via mobile devices from a network performance/gains perspective.
I have previously blogged about Activity Timelines when they were first announced here. They are brilliant replacement for the Social Pane in the UUI; they reduce the white space and provide excellent filtering and search capabilities for the type of records the Users wish to see whilst providing you a highlighted list of what has happened since you last accessed that record! They look exactly the same on the Mobile devices except you have the ability to upload media (videos, audio and pictures) directly from your device.
With the new Apps and the new controls available, the way users can interact with their organisations Dynamics 365 implementation is growing and making use of the latest technologies. The new controls should help with users interfacing with their devices whilst reducing the number of clicks or taps that would have to complete with the web client or earlier versions of the Mobile Apps.
I often see people asking or wondering how they can install the Microsoft Dynamics 365 App for Outlook (Cloud based addin). Currently (at date of publish), this is still available in preview only i.e. you can see the big PREVIEW text whilst using the App and requires additional steps to configure on top of the prerequisites.
Dynamics 365 V9.0 is currently online only, so on premise D365 V9.0 configurations are not applicable at present; I expect this will soon change due to the V9.0 Customer Driven Updates (CDU) being shortly available.
Trying to configure the preview version of the App for Outlook can be a pain if you have not met all the pre-requisites which Microsoft layout in their basic steps listed here:
Please read the disclaimer on the page that looks like this:
Microsoft assumes you have setup an Office 365 tenant with Dynamics 365 and Exchange Online where Users have been assigned a license for each product or where they have a Dynamics 365 License and access to a supported Exchange mailbox for the addin to be installed too. You cannot just go in and setup a Dynamics 365 trial and expect it to just work – in fact, you actually have to enable the preview before you can get to the App for Outlook sitemap area.
The next sections will detail the steps allowing you to complete the setup from start to finish and end up with a working App for Outlook. This can take up to an hour or so to complete due to the provisioning of services and Users Mailbox, the Exchange services and associated mailboxes take the most time to provision here.
As this guide is creating a trial (most likely for demo/testing purposes) – then it is assumed that the User is the Global Office 365 Admin; this speeds up any privilege issues that may arise. But otherwise you will need a CRM Service Admin and Exchange Service Admin privileges in O365 for the initial configuration.
What are the configuration steps?
So from a high level – what actually needs to be configured or created?
Creation an Office 365 Tenant
Setup a Dynamics 365 Trial
Setup an Office 365 Trial (E3 or E5)
Assign User Licenses
Create the Users Mailbox and set it up
Configure Email Setting and User Mailbox in Dynamics 365
Enable the App for Outlook Preview
Add the App for Outlook the Users mailbox in exchange
Once all these high level steps have been completed, the Users will be able to use the App for Outlook! Simple huh?
Steps 1,2 – Provision a Dynamics 365 Trial
The quickest way I have found to kick start this whole process is to create a Dynamics 365 trial (which also creates the Office 365 tenant), this process can be kicked off at the following site (UK link):
Complete/follow the steps to create the CRM instance.
Choose your additional solutions.
Login to Dynamics 365 after it has been provisioned.
Once you can finally see the D365 Sales area – your done! (This part at least).
This process can take up to 10 minutes to complete depending on what items you select when you want to use CRM. When setting up a Dynamics 365 trial, I usually install none of the additional solutions as you can do that separately with the Dynamics 365 Admin area once CRM is provisioned unless I explicitly know what the trial is going to be used for, i.e. PSA or FSM.
Step 3 – Exchange/Office 365 Trial
To set up Exchange (just the basic setup, no special requirements) – the easiest way is to select one of the Office 365 E3 trials to the Office 365 tenant. To do this:
Navigate to the Admin area in Office 365.
Click on Billing > Subscriptions > + Add Subscriptions.
Select Office 365 E3/E5 – click Start Free Trial.
Confirm the Order.
Microsoft will be provisioning the services in the background and may take up to half an hour to complete the set up of Office in your tenant.
Step 4 – Add Users/Assign Licenses
Whilst you are waiting – add any Users you require to your tenant and the assign them licenses to both Dynamics 365 and Office 365 E3/5 plan.
To add users:
Navigate to Office 365 Admin area.
Click on Users.
Click on Active Users.
Click + Add User.
Fill in required information.
In the Product Licenses area, select the Dynamics 365 and Office 365 Licenses.
To add Licenses to existing users:
Navigate to Office 365 Admin area.
Click on Users.
Click on Active Users.
Select the User(s) you want to assign licenses to.
Click on the Edit product licenses menu item.
Select add existing assignments.
Select the Dynamics 365 and Office 365 Licenses.
Users will then eventually have access to both Dynamics 365 (when they are assigned a Security Role) and their Mailbox in Exchange. This may take up to 15 minutes or so! The next set of steps can be performed whilst this action occurs in the background to save some time.
Additionally, Users in CRM will need a Security Role with the “User Dynamics 365 App for Outlook” Security privilege:
Step 5 – Mailbox Configuration
Users actually have a few more steps to complete personally to configure their mailbox; this could probably be done in an automated way by an exchange admin – but I have not investigated this or know how to do this.
When the Office Mail icon appears – this means that their mailbox is ready!
When Users click on this – they will be asked to select their Timezone and Language/Format.
Set this accordingly and then they should be able to log into Outlook for Web (OWA).
This step will confirm that the mailbox exists in Exchange – and will ensure that the addin will be installed first time and not get stuck in a pending state.
Step 6 – CRM Email and Mailbox Configuration
For the App for Outlook to work with Exchange/Dynamics – all synchronisation methods must be set to Server Side Synchronisation.
The default CRM setting should be set and each of the Users mailbox records should also be set accordingly, their email approved and the mailbox Tested and Enabled.
Navigate to Settings > Administration > System Settings
Click on the Email Tab.
Set the Synchronisation Method to Server Side Synchronization for all, Incoming Email, Outgoing Email and Appointments, Contacts and Tasks.
Once these items have been completed – navigate to each Users Mailbox record and perform the following:
Navigate to Settings > Email Configuration > Mailboxes.
Select the User(s) mailbox records.
Click on Apply Default Email Settings button in the Command Bar.
Click on Approve Email button in the Command Bar.
Click on Test and Enable Mailbox.
If their mailbox has not yet been configured this will fail – so please complete step 5
Once successful – this will be highlighted:
The App for Outlook pre-requisites should be now met.
Step 7 – Enable the Preview – App for Outlook
For Dynamics 365 V8.X – the App for Outlook sitemap area would be visible under the Settings area.
With V9.0 by default – it is not there:
This is where it needs to be enabled as it is in Preview.
Navigate to Settings > Administration > System Settings.
Click on the Preview Tab.
Read the License Terms (Optional) and check the I have read and agree to license terms.
This enables the sections that were greyed out.
Navigate to MailApp Preview > Enable Dynamics 365 App for Outlook Preview = Yes.
Click OK and close the System Settings window.
This is where the magic happens – hit CTRL + F5 to refresh the page, the Sitemap item should appear under the System group!
Step 8 – Add the Addin
One the Preview has been enabled – you can now add Addin to all Users whom meet all the pre-requisites.
Navigate to Settings >System > Dynamics 365 App for Outlook.
Select the User(s) you wish to add the App for for Outlook too and click either Add App to Outlook or Add App for all Eligible Users.
Whilst the installation is pending, this will be installed to the Users Exchange Mailbox.
When it has been completed:
Once it has been added – the User can use the Addin in Office!
Step 9 – Use
Open OWA – open an email or send one and the addin should be viewable!
Thank you for reading – I hope this article helps you take a trial run of the App for Outlook for Dynamics 365!
Last year, I started writing a couple of blogs for the July 2017 release of Dynamics 365 and the Unified User Interface (UUI) as part of a team testing out the new capabilities in V9. The teams objective was to feedback our findings with the Dynamics 365 community, listing out the new features and any new functionality discovered or if there are findings which may be considered an issue or problem for organisations looking to upgrade to the latest version of Dynamics 365.
My latest series, “Introduction to the Dynamics 365 Mobile Apps for V9.0 ” details our findings using the new mobile applications and the UUI. The first and second blog posts can be found here:
My previous blog (part 2) discussed the different types of Mobile App available for Dynamics 365 Users and how they could install the Dynamics 365 Mobile Applications for a Tablet or Phone device. Installation requires that the users would have a device matching the Hardware Requirements for Tablet or Phone version and also permitted to download the App onto their devices.
Additionally, Users require a Security Role with the correct privilege to access Dynamics 365 via the Mobile App; this point should really have been apart of this blog as it requires a change to Dynamics 365 customisations (i.e. Security Role change which is then granted to the users whom require mobile access).
This main subject for this blog will talk about what configuration items are required to be completed to allow Users to connect to their Dynamics 365 instances using either the Phone or Tablet App and utilising the Customisations which have been enabled for mobile use. I will discuss new features (such as the Custom Controls) in my next blog.
The are two main topics that will be covered (and broken down into smaller components):
Configuring the Mobile App – connecting the app to Dynamics 365 and setting it up for first time use.
Mobile Customisation – making changes to Dynamics 365 to allow items to be used on a mobile device.
Configuring the Mobile App
Installation of the Mobile App (Tablet or Phone) is the first step – the next step is to connect the app to the Dynamics 365 organisation.
My first assumption is that you are using an online organisation and Dynamics 365 V9.0 (at the date of this blog, V9.0 is only available for online instances). The screenshots below are for an online trial org and using the Dynamics 365 app on an iPad.
Connecting to Dynamics 365
To connect the mobile app to Dynamics 365 please follow the following steps:
Open the app on the chosen device.
Wait for the organisation URL page (let’s get set up) to display.
Enter the URL for your organisation in the format https://ORGNAME.crmX.dynamics.com – where ORGNAME is the instance unique name for your CRM organisation and X is the region of your CRM data-center. (i.e. for Europe it is CRM4 or CRM11 for UK).
Click the next button.
Enter your credentials into the Microsoft sign in page and click login.
The Dynamics 365 Welcome page should display.
Once the login has completed, Users will be presented with a list of “Apps” to select which are available in the Organisation. The screenshot below shows the available apps in my trial organisation:
The available Apps are the modular UUI Apps which I have previously mentioned, these will be discussed in the next section.
There are some basic settings that can changed without actually accessing one of the Modular apps and will affect how the Mobile Application is interacted with. The menu can be accessed by clicking the middle cog icon.
These are the same settings as the User can set in the web client (but a cut down version). The last option – Records per page may be a performance hit on slower connections if a greater number of records is returned.
This settings area allows User to define how the Mobile Application will interact with the device.
With Dynamics 2013 – Dynamics 365 V8.2, there were multiple changes needed to CRM from a customisation perspective to allow users to use the mobile applications and what objects they could interact with on their mobile devices (such as entities and fields).
Some of this customisation changes are still needed, but Microsoft have now provided us with greater control on how to complete this task and with greater efficiency through Modular Apps!
There are two main levels of configuration changes that need to be made to Dynamics 365 to allow Users to interact with Dynamics 365 and a chosen set of customisations on their mobile devices:
Security Privileges – discussed in my previous blog; but this allows the Users to connect to Dynamics 365 using the Mobile Applications when the User has a Security Role with the Privilege enabled.
Modular App with UUI
With Dynamics 365 (V8.2) – Microsoft released the App Designer which brought allowed system customisers to build modular apps in CRM – this would collate the following components into a single accessible area of CRM which would not show any areas that are not relevant to the Users, but only the components which are included with the App:
Business Process Flows
Each Modular App has its own Sitemap also – so the Users can have a personalised user experience i.e. not displaying the out of the box sitemap items which may clutter the User Interface.
With Dynamics 365 V9.0 – Microsoft released the new Unified User Interface which is a consistent framework across multiple devices. Any customisations made in the UUI would apply to any device that the Users access the Dynamics 365 instance. The UUI has replaced the MOCA framework which is what the Interactive Service Hub and the Mobile Applications were initially built on.
Modular Apps are now client specific, meaning that they can be created to run through the Web Client or the Unified Interface.
The web client Apps can only be used on a PC using an internet browser such as Edge or Chrome where as the UUI Apps can be used through a browser or across multiple devices through the Dynamics 365 Mobile Applications where set of components included with the modular App look the same across each device.
Creating a Modular App
This blog will not walk through creating a Modular App with the new App designer – the following link (Microsoft guide) will walk you through creating a modular app:
Once you have, saved and published your Modular App (make sure it is set to UUI!), you can then select the App which will then allow you to view your customisations in the mobile application via the App selector.
App Security Roles
Remember to set/allow Security Roles to access the Modular App so Users can access the Modular App on their devices (which you can actually do from the Mobile Clients)!
Navigate to the Modular App on the Mobile Device.
Click the Ellipses (…).
Click Manage Roles.
Select the Roles you wish to allow access to (remember the roles should have the correct permissions for each Entity in the App).
Sitemap with Icons!
When creating a Modular App – the Sitemap can also be configured which is now also visible on the Dynamics 365 in its complete form!
Sitemap in the designer.
Sitemap in the Web UUI.
Sitemap in the Dynamics 365 Mobile Application (the last icon is the default one for comparison).
Looking at the Web UUI and the Dynamics 365 Mobile Application, there are some custom icons which have been added (I have used the Visual Studio Icon library set) to the custom Entities. The formats for these are as follows:
I uploaded mine using Iconator with the XRM Toolbox!
Reading through the mobile app configuration documentation (link here) refers to be mobile customisations that are still aimed at a Dynamics CRM 2013 – Dynamics 365 V8.2 implementation.
Additionally, navigating to the customisation section of the Enterprise Edition which can be found here, this section also describes the “Code once deploy everywhere” but is also based on the old configuration items such as the options which needed to be set to enable the Entities, Dashboards and fields for mobile use.
Through testing, I have gone through and tried all the different settings that used to be required (enabled) for mobile use – and here are my findings:
Entity Settings Level
Entity – Enable for mobile (above).
Entities no longer required to be enabled for mobile, this has no impact if this switch is toggled.
Dashboard – Enable for mobile (above).
Dashboards are no longer required to be enabled for mobile, this also has no impact if this switch is toggled.
Fields, Tabs and Sections
Fields – Available on phone (above).
Fields are no longer required to be flagged for phone availability, but Tabs and Sections visibility (on the mobile device) is still controlled via the flag in the properties to enable them on the Mobile Application.
The Tab (5) and Field (75) restrictions seem to be lifted – I have confirmed this via more than 5 tabs and 75 fields and none are removed on the mobile device!
8 Tabs and more than 75 Fields above on the Registration Form viewed on an iPad
Tab Selection displayed through the Mobile Application on the iPhone.
This completes my brief guide on the configuration items required for allowing Users to access and use the Dynamics 365 Mobile Applications on their devices. I have tested a few of the old customisation items where by you were required to set a flag to enable the component for mobile use.
Most of these flags have been succeeded/replaced by adding the component (i.e. Entity or Dashboard) to the Modular App which are then inherently available through the Mobile Application.
As mentioned previously, my next blog will detail some of the newer features available on the Mobile Application, such as Custom Controls and Task Flows etc.
I am writing a series of blogs that will serve the readers as an introduction to the Dynamics 365 Mobile Apps for the latest version of CRM known as Dynamics 365 July Release (V9.0).
This is part 2 in the series – I hope the (series) blogs can be used as a reference guide for CRM Consultants/Customisers or administrators when deploying Dynamics 365 in their organisation or on behalf of their customers. I will highlight the key functionality of the mobile apps within the UUI framework.
I will assume you have now decided that you intend to use the Dynamics 365 Mobile Apps – so my aim for this blog is to cover the following questions:
What are the mobile apps and types (of app) available with Dynamics 365?
How can you get the mobile apps and what are the prerequisites that need to be met?
How to you install the app to your devices?
I will post links to the official documentation/articles by Microsoft from their new documentation site for Dynamics 365.
Mobile Applications for Dynamics 365
Types of Mobile App
There are several types of mobile applications available to Users for accessing their Dynamics 365 data on their device, these are:
Microsoft Dynamics 365 Mobile Apps
3rd Party integrated – developed externally by 3rd party providers
Microsoft Dynamics 365 – Mobile Apps
Base Phone and Tablet Apps
There are currently 2 offerings of the mobile applications for Dynamics 365, these are:
Dynamics 365 for Phone
Dynamics 365 (for Tablets/Windows 10 Devices)
These two apps are the focus of these articles and the topics will be based around the functionality provided by Microsoft. From a customisation perspective – they are using the same set of Dynamics 365 customisations*, but the content that is displayed will be in a different manner on the smaller phone screens compared with the larger tablet screens.
The next few sections will list out other options available for mobile applications which are linked to Dynamics 365 but are not the focus for this blog series. (There are 1 or 2 I will not be mentioning as they have either been deprecated, like the Project Services Finder App – which has been replaced with the base apps or have been removed from the product).
*depending on which modular app they are using
Before we talk about the additional out of the box app offerings, I need to briefly describe about the concept of modular apps (a set of customisations and sitemap) within the XRM platform in Dynamics 365. These type of ‘Apps’ could be created using the App Designer to build up a particular area of CRM with a distinct set of functionality.
The app then filters the users view of CRM (via Entities/Forms/Views and sitemap) to the areas which are apart of the App allowing to them to stay focused on the key Entities that they interact with to complete their day to day tasks.
These have now been expanded to be configured to use the Unified User Interface (UUI) (more to come in a later blog). These apps will form the framework of a set of customisations that will be used for the base mobile apps for Dynamics 365.
App for Outlook
The new Outlook integration is now based on the UUI and actually runs in the context of a modular app in Dynamics 365. Technically, this is an exchange level mailbox add-in and not a standalone application or client that needs installing to your device, but it can run directly from your mobile Outlook application running the new UUI!
If you would like an introduction into the App for Outlook as a mobile replacement for your Outlook Client (for Dynamics 365) – please read my earlier posts:
Microsoft acquired Field One back in 2015 which had a CRM addon for Field Service Management functionality. The goal of FieldOne is to provide organisations who offer customer services in the field a better way to manage and provides these services to their customers. Field Service engineers would need away to access the data to complete their assigned task in the field (more often than not) remotely through their mobile device.
Microsoft took the opportunity to integrate the FSA capability provided with FieldOne into the Dynamics 365 platform and re-branded the solution as Field Service Automation (FSA) which was built up as a modular app within the XRM platform and can be installed through the Dynamics 365 Admin Center as an addin solution.
The associated mobile application (for phones/tablets) is called “Field Service- Dynamics 365” which is available to Dynamics 365 Users who have been provided the correct License Type. This is one of the Apps that Dynamics 365 Users can use to access their Field Service data but requires some additional installation of a CRM solution from Resco as described here.
I envisage that the base Dynamics 365 Mobile Apps will have their functionality/capabilities expanded over a period of time and will eventually replace the Field Service App.
This may be achieved through the new Custom Control Framework (CCF) which is very hush hush at the moment and most likely under NDA for partners! Jukka Niiranen wrote a very good blog about the prospect and future use of the CCF here.
Additional MS Mobile Applications
The Microsoft stack is growing and growing – new ways to access your Dynamics 365 data are also increasing such as the introduction of PowerBI, the Common Data Service, PowerApps and Flow.
PowerApps and PowerBI are great new ways of interacting with your Dynamics 365 – PowerBI for reporting and PowerApps to build custom “throw-away” apps to perform a particular set of tasks. They both have a mobile offering also!
3rd Party Integrated
Resco purchased CWR a couple of years ago and is now the largest 3rd party add-on provider for mobile solutions which is built on top of Dynamics 365.
As it is a 3rd party addon, there is an additional cost (per user/server) to organisations who wish to use the Resco solution (unless its in-conjunction with FSA – see above!).
Whilst there are still quite a few offerings to access Dynamics 365 data on a mobile apps available to organisations and its users, I will be purely focusing on the base Dynamics 365 mobile apps for this blog series.
How do I get the Apps?
The App Store
Ultimately, you can download the Dynamics 365 mobile apps through your devices App Store. If your mobile device is a part of an enterprise device management policy – you may have a dedicated app store for your organisation where you can only download authorised “Apps” from; you may need to ask your IT department to make this available for your organisation. But before you do, it may be best to check the prerequisites of the mobile apps!
Firstly there are two things to consider before installing the Dynamics 365 Mobile Apps:
I will make the assumption you are using CRM Online (as V9.0 has not yet been announced for on-premise release).
Previously – Microsoft issued a supported device listing for the the mobile apps along with an operating system version. With the latest documentation, Microsoft just list the supported operating systems and recommended device specifications.
For users to be able to access your Dynamics 365 organisation with the Mobile Applications – the following security privilege will need to be assigned to the users (details here) via an assigned Security Role.
Open a Security Role
Navigate to the Business Management Tab
Scroll down to the Privacy Related Privileges
Set Dynamics 365 for Mobile = Organisation
This screen shows the out of the box sales person role which has the privilege enabled by default.
Installing the App
I will show you quickly how to install the app to your device – my screenshots are of the installation being completed on iPhone 6 with iOS 10 to install this through the Apple App store. This assumes that you can download the app through the devices default app store – otherwise you may need to select it through your organisations app store.
Navigate to the App Store and find the app (i.e. search by typing Dynamics 365)
Download the App by clicking “Get” or the Download icon.
Wait for the App to be installed and click open.
Or find the Dynamics 365 for Phones App icon on your home screen
Wait for the App to open and display the Organisation URL page!
The full (its shorter than above) installation guide can be found here:
The Dynamics 365 Mobile should be ready to be configured – I will go through the configuration in my next blog as that will need to cover a few items in CRM.
I hope you have found this article of use – it will probably be my last of 2017, but I may find some time to right the next article before the year is out (assuming my trial has not run out!). I hope you all have a lovely Christmas and I wish you all a happy new year!
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!