With the introduction of the new Unified Interface in Dynamics 365, you may want to be able to detect if the current form is being rendered in the Unified Interface or not in JavaScript.

It is possible to do this with an internal function: Xrm.Internal.isUci(). This function will return true if called from within the Unified Interface, and false if not.

Being an internal function, this function is not supported code. However, since a likely reason to want to run this in the first place is due to not wanting some existing unsupported code to run in the Unified Interface (or the opposite with some new unsupported code that targets the Unified Interface…) that’s probably not a deal breaker for using this.

Microsoft’s Bot Framework is available for developers to create and connect interactive bots to everyday conversational platforms such as Skype, Facebook Messenger and Microsoft Teams. The QnA Maker is a service that provides a quick and easy way to add question and answer support to your bots and apps. The bot will be able to take a User’s questions and respond back in a natural way and all this can be developed and deployed very simply. This blog will go through an example using a product manual to create a question answering bot.

To start you would need to navigate to https://www.qnamaker.ai/, sign in using your Microsoft Account and then select ‘Create a knowledge base’. The first two setup steps shown in the screenshot above require you to create and select a QnA Service. Selecting the ‘Create a QnA service’ button will redirect you to the Azure Portal, guiding you in creating your own service.

Step 3 will allow you to name your knowledge base, followed by Step 4 which is used to populate it. To populate your knowledge base, you can provide a URL for a data source, a document file such as a word or pdf file or you can leave this part empty and populate the questions and answers manually once it has been created.

In the example above, I attached a user guide for the Samsung Galaxy S9 as my knowledge base source. After adding the pdf file and selecting ‘Create your KB’ in Step 5, the QnA bot knowledge base began populating. Around two minutes later my knowledge base was ready to be tested. The screenshot below shows a snippet of the 33 pages worth of questions and answers created from the attached pdf.

After selecting ‘Save and train’ in the top right corner of the screen, I was able to test my QnA bot within the browser with the ‘Test’ button. The screenshot below shows a test conversation. As you can see there is already some language understanding capability during testing as it was able to connect the input question to correct answer. If you select ‘Inspect’ from this test window, you’re able to see the returned answer with a confidence score and alternate answers, which could have been returned. From this window you can select preferred answers and even provide more answers.

Once you’re satisfied with the QnA source you have created, you can select the Publish button and publish the QnA knowledge base to be used publicly. The success page will provide you with a sample HTTP request, which you can use to connect your newly created service to a bot or an app.

In my previous series I demonstrated, ‘Configure SLAs for Opportunity in Dynamics 365’, I demonstrate how to enable Opportunities for SLAs and how to implement three SLA KPIs for Opportunities. This approach works well when the SLA KPIs on the same SLA are all Applicable From the same date and time. However, the demonstration showed this approach does not work when some of the SLA KPIs on the same SLA need to be Applicable From a different date and time.

In this series I will describe an approach, using the same scenario as that used in my first series, that demonstrates how to implement the three SLA KPIs for Opportunities in such a way that they work accurately.

As a reminder, the SLA KPIs that will be implemented are:

• •First Response By; i.e. the time taken to send a Quote to the Customer after an Opportunity has been created; e.g. within 1 hour.
• •First Response After Quote Accepted By; i.e. the time taken to contact the Customer after they have accepted the Quote to acknowledge receipt of their acceptance and confirm details for delivery; e.g. within 1 hour.
• •Order Sent By; i.e. the time taken to send an internal Order to a Store for fulfillment after the Customer has accepted the Quote; e.g. within 2 hours.

The Applicable From date and time for the first SLA KPIs is from the Created On date and time of the Opportunity. The Applicable From date and time of the other two SLA KPIs is from the Quote Accepted date and time.

The configuration requires completion of the following steps:

• •Add a custom entity named SLA Instance.
• •Enable the SLA Instance entity for SLAs.
• •Add a custom Applicable From date/time field to the SLA Instance entity.
• •Add custom Quote Sent, Quote Accepted, First Response After Quote Accepted and Order Sent date/time fields to the Opportunity entity.
• •Add a custom 1:N (one-to-many) relationship from Opportunity to SLA Instance.
• •Add a custom 1:N (one-to-many) relationship from SLA KPI Instance to SLA Instance named SLA KPI.
• •Create and activate an SLA with related SLA Items for SLA Instances.

This approach does not require enabling the Opportunity for SLAs or the creation of any relationships from the SLA KPI Instance entity to the Opportunity Entity.

The following Entity Relationship Diagram (ERD) shows the entities and relationships.

The following image shows an example of a custom SLA tab on the Opportunity form displaying the SLA and SLA KPI information in the SLA Instances subgrid where each of the SLA KPIs have been successfully met.

Note: The Warning Time and Failure Time for the First Response After Quote Accepted SLA KPI and Order Sent By SLA KPI have been calculated from different Applicable From date and time as the First Reponses By SKLA KPI and so are accurate.

In my next article I will demonstrate how to configure the SLA Instance entity for Service Level Agreements (SLAs) in Dynamics 365.

Magnetism and our clients submit service requests to Microsoft for any issues and problems dealing with Microsoft Dynamics 365. These problems usually require investigation from Microsoft or are issues we have no control in resolving (which are becoming more prevalent as more clients are moving into the cloud).

When submitting a ticket to Microsoft support, you can expect slow response times if you do not provide enough information. It is very important to supply as much information as possible, so a support agent can provide you with the best level of support as fast as possible.

In this blog, I will go over how to log a service request to Microsoft for issues with Dynamics 365. I will also cover ways how you can get a quicker response from Microsoft Support and quickly resolve these issues. Note that this blog focuses on Dynamics 365 Online.

To be able to submit a Service Request to Microsoft for a given Dynamics 365 instance, you would need to have access to the Office 365 Admin Portal. You can go to this by navigating to https://portal.office.com/adminportal/ or from Dynamics 365 by clicking the App launcher and selecting Admin (found in the top left-hand corner of Dynamics 365 in the browser):

In the Office 365 Admin Portal, in the navigation menu, under Support, click “New service request”.

This will open a “Need help?” form in the right-hand side of the browser. From here, you will fill in the text box to describe what issues or errors that requires action from Microsoft. It is important that for Microsoft to resolve this issue as fast as possible, we need to assist them in their investigation. This means being descriptive and detailed, such as stating the steps in reproducing the issue, what you would expect versus what is happening, and details about the error being display on screen.

What should be done next is instead of submitting the entered query in the text box by pressing Ctrl + Enter, you need to click the “Get help” button. What ends up happening is that the greyed out, faded and unclickable (it appears to be almost hidden) “View solutions” and “Contact us” controls are refreshed. Both these controls get activated to be accessible and can be clicked to be expanded (the “Contact us” control is replaced with “Let us call you”).

From here you’d want to submit your contact details such that Microsoft is able to contact you regarding the ticket. What is also important here is the ability for you to submit attachments (which a normal service request query cannot do). This is important because it gives you more flexibility in what kind of information you can give to Microsoft to aid them in their investigation. Attachments allow us to include screenshots, log files, and other files. After submitting all of this by clicking the ‘Call me’ button, a Microsoft engineer from their support team will usually contact you with your issue via phone call.

Here are a few pointers on what you can state and declare when submitting a query:

• • •  Steps to Reproduce – what specific steps did you take to encounter or to reproduce the issue e.g. opening an entity record and clicking the Mail Merge button, tracking an Appointment against a Lead record in Dynamics 365 App for Outlook, resetting the Sandbox instance in the Office 365 Admin Center.
  • •  Acceptance Criteria – what you expect to happen vs. what actually happened e.g. a prompt pops up in the screen when I click the Deactivate button on an Account, but it instead causes the browser to display an HTTP 404 Error.
  • •  Impact – how many users are affected, are there any workarounds to the issue, if there is no workaround is the service I am providing or is the functionality completely unavailable.
  • •  Attachments – include screenshots, log files (when the error prompt allows you to ‘Download Log File’), and other files.

Service requests allows us to log any questions or issues relating with Office 365 and Dynamics 365. I hope this blog gives you a guide in not only logging a service request, but also how to log a service request such that it can be acted on and be resolved by Microsoft at the quickest time possible. By being able to specify as many details regarding the question or issue, we can respond and resolve these with Microsoft without being impeded in our everyday use of Dynamics 365.

↩ Part 1 - Multiple SLAs with Different Dates in Dynamics 365

In this article I will demonstrate how to configure the SLA Instance entity in Microsoft Dynamics 365 for Service Level Agreements (SLAs).

In this approach the SLA KPIs are tracked against the SLA Instance rather than against the Opportunity. One Opportunity related SLA Instance will be created and used for each SLA KPI being tracked. The Name of each SLA Instance will be used to denote the SLA KPI; e.g. First Response By. Because of this the Name field on the SLA Instance entity will be renamed to KPI.

Create and Configure the SLA Instance Entity

Create a custom entity named SLA Instance. I might have named this entity ‘Opportunity SLA’ but have chosen to use a generic name because this same entity may be used for other related entities in addition to Opportunities for tracking SLA KPIs against.

Enable the SLA Instance entity for SLAs. The ‘Enable for SLA’ option is located on the General tab of the entity. In this this approach the SLA Instance rather than the Opportunity entity is enabled for SLAs.

When the SLA Instance entity is enabled for SLAs the following fields are then automatically added to it. These are used by the Microsoft Dynamics 365 Service Level Agreements functionality.

Change the Display Name of the Primary Field for the SLA Instance entity from Name to KPI and configure this field to be Business Required.

Add the following 1:N (one-to-many) Relationship from the Opportunity to the SLA Instance entity.

This results in the addition of a corresponding Opportunity Lookup field to the SLA Instance entity.

Add SLA Specific Fields to the SLA Instance Entity

Add the following field to the SLA Instance for use by the SLA. In this example I have chosen to use a custom field named Applicable From to be used by SLAs as the date and time from which the SLA KPIs are applicable. In this approach the Applicable From field is added to the SLA Instance entity rather than to the Opportunity entity and is configured to be Business Required.

The addition and use of this field is optional because the standard Created On field might be used instead.

Add SLA Item Specific Fields to the Opportunity Entity

Add the following fields to the Opportunity entity for use by the SLA related SLA Items.

These fields are specific to the scenario described in the first article of this series.

• •Quote Sent is used to record the First Response date and time.
• •Quote Accepted is used to record Quote Accepted date and time.
• •First Response After Quote Accepted is used to record the First Response After Quote Accepted date and time.
• •Order Sent is used to record the Order Sent date and time.

In your own implementation you will have a different set of fields that are used to track the steps in the business process you are implementing SLAs for.

In my next article I will demonstrate how to configure a single custom generic SLA KPI for use with SLA Instances and how and why this differs dramatically from the approach used in my first series.

We recently ran into an issue where global search results for one of the entities wasn’t showing any data in the fields, for a system upgraded from CRM 2011 to Dynamics 365. The version of Dynamics 365 we used was 8.2.0.749.

Upon digging further into this issue, I figured out that no column was selected as find columns in Quick Find view of the affected entity. In this instance it is Contact entity. This is somewhat strange because if we don’t select at least one column in the find columns, Dynamics 365 prevents us from saving the Quick Find view. How this happened is still unknown.

However, the fix to this issue was selecting at least one column in the find columns of Quick Find view. Once the change was saved and published I used the Global Search using same query. This time the resulting records for Contact entity had data in the fields.

↩ Part 2 - Create Custom SLA Instance Entity in Dynamics 365

In this article I will demonstrate how to configure a generic custom SLA KPI for use with SLA Instances in Dynamics 365 and how and why this differs dramatically from the approach used in my first series.

In my first series I described the creation and use of three SLA KPIs for use with Opportunities. These were then used to configure the SLA Items on the SLA. In this approach we only configure and use one generic SLA KPI, named SLA KPI, for use with SLA Instances. In the configuration of SLA Items and the creation of SLA Instances, the Name of the SLA Instance, rather than the selected SLA KPI on the SLA Item, will be used to denote the SLA KPI; e.g. First Response By. However, we do need to create and use one generic placeholder SLA KPI for use with SLA Instances.

Configure SLA KPIs for SLA Instances

Add the following 1:N (one-to-many) Relationship from the SLA KPI Instance to the SLA Instance entity. The Field Name of the Relationship is SLA KPI. In this approach the Relationship is added to the SLA Instance entity rather than the Opportunity entity.

This results in the addition of a corresponding SLA KPI Instance Lookup field to the SLA Instance entity. In this approach this field is configured as Business Required.

This also results in the addition of a corresponding SLA KPI option, named SLA KPI, for use by SLA Items associated with SLAs created for the SLA Instance entity.

In my next article I will demonstrate how to configure the forms and views for SLA Instances, SLA KPI Instances and Opportunities for displaying the SLA and SLA KPI Instance information in Dynamics 365.

Adaptive Cards are a great way to display an interactive card-like interface within applications like Outlook, Microsoft Teams, Bots and many more. The screenshot below shows a simple adaptive card which can be shown in different web chat channels and has a variety of text, an image and two buttons. These adaptive cards are very customizable and are very consistent with the channels they are in.

Each adaptive card is a simple JSON object and customizing this card is as simple and adding to the JSON. The screenshot below shows the JSON for rendering “Jordan Hohepa” and “CRM Developer” in the adaptive card above. To test out creating and customizing adaptive cards online you can visit https://adaptivecards.io/ and navigate to the ‘Visualizer’ tab.

The screenshot below shows an email I have received via Outlook which contains the adaptive card I had created above. Like the card earlier, it is fully interactive within the email itself. Although this has been a simple example, you can see how these cards could be useful. In the case of Outlook, Users won’t need to navigate away from their inbox and will be able to view and interact with the cards as they need to. To send the Adaptive Card below I used Microsofts ‘Actionable Message Card Playground Tool’ which allows you to create the card as JSON and send it to yourself for testing purposes. At the time of writing this blog the Tool can be found at https://messagecardplayground.azurewebsites.net/.

The button logic is also configurable within the JSON schema of the adaptive card. The screenshot below shows the contents of the ‘Save’ button, which has a text field element and a button element inside. The button which is labelled ‘Send’ has an Http Request action connected to it, which will POST data to a provided URL. The action can contain a Custom URL, header values and body text, which in this example would be taken from the input of the textbox by using the id set as “sendText” within two curly brackets.

The result of the above schema can be seen in the screenshot below where the Save button expands a drop down showing the textbox and the Send button.

 
The example in this blog is very simple but the functionality shown can be re-used within real life situations, whether it’s something like providing feedback directly within the email itself or booking a flight overseas. One feature recently announced was the ability to integrate payment actions within these adaptive cards. With this Users would be able to pay for things without the need to leave Outlook.

↩ Part 3 - Configure KPIs for Custom SLA Instance in Dynamics 365

In this article I will demonstrate how to configure the forms and views for SLA Instances, SLA KPI Instances and Opportunities for displaying the SLA and SLA KPI Instance information.

Configure SLA KPI Instance Quick View Form for use on SLA Instances

Add the following SLA KPI specific Quick View Form to the SLA KPI Instance entity. Note: In this approach, this Quick View Form will be displayed on the SLA Instance Main Form rather than on the Opportunity Main Form.

The following shows the layout of the SLA Instance SLA KPI Quick View Form. The form simply contains a Timer Control configured as shown in the following image.

The Timer Control is configured as follows:

This Quick View Form will be added to the SLA Instance Main Form to display the SLA KPI Timer as shown in the following images for the First Response By SLA KPI. In this approach the SLA Timer cannot be displayed on the Opportunity Main Form but is instead displayed on the SLA Instance Main Form.

Configure SLA Instance Views for use on Opportunities

Add the following View to the SLA Instance entity. This View will be used to display the SLA Instances in a subgrid on the Opportunity Main Form. In this approach SLA Instances rather than SLA KPI Instances are displayed in a subgrid on the Opportunity form.

This View displays the following columns from the SLA Instance: SLA, KPI and Applicable From and the following columns from the related parent SLA KPI Instance: Status, Succeeded On, Failure Time, Warning Time.

Configure the Main Form for Opportunities

Add an SLA tab and related components for the SLA and SLA KPIs to the Opportunity Main Form.

In this approach the SLA KPI Instance Quick View Forms and an SLA KPI Instances subgrid cannot be displayed on the Opportunity Main Form. An SLA Instances subgrid rather than an SLA KPI Instances subgrid is displayed on the Opportunity Main Form. There is also no SLA or Applicable From field displayed on the Opportunity. These fields are instead displayed on the SLA Instance Main Form.

• The First Response By SLA KPI section displays the Quote Sent date/time field.

• The First Response After Quote Accepted By SLA KPI section displays the Quote Accepted and First Response After Quote Accepted date/time fields.

• The Order Sent By SLA KPI section displays the Order Sent date/time field.

• The SLA Instances section displays a subgrid for the related SLA Instances. This subgrid is configured as shown in the Set Properties image.

Configure the Main Form for SLA Instances

Configure the SLA Instance Main Form as follows. The components displayed on this form are the Opportunity, SLA, KPI (Primary Field) and Applicable From fields and the SLA Instance SLA KPI Quick View Form. In this approach the SLA, Applicable From and SLA KPI Timer is displayed on the SLA Instance Main Form rather than on the Opportunity Main Form.

The SLA KPI Instance SLA KPI Quick View Form is configured as follows:

In my next article I will demonstrate how to configure an SLA for Opportunity related SLA Instances with multiple SLA Items for the same SLA based on the three SLA KPIs previously described in this series.

I have a user who has encountered an issue where, when they are viewing their Outlook Add-ins via the ‘Manage Add-ins’ page, the Dynamics 365 App for Outlook Add-in is missing. What was interesting is that Dynamics 365 has indicated that it has already been installed and has already been ‘Added to Outlook’ via the App for Outlook Settings in Dynamics 365.

To view your Outlook Add-ins in Office 365, go to https://outlook.office365.com and log in using your Office 365 credentials. In Settings, navigate to Manage Apps via: https://outlook.office.com/owa/?path=/options/manageapps.

A bit of context on how the user has encountered this issue: they were conducting pilot testing to test the functionality of the new Dynamics 365 App for Outlook to eventually replace the Dynamics CRM Outlook Client. The user initially had the Dynamics 365 App for Outlook connected to their organization’s sandbox environment but have switched the connection to the production environment. Switching the connection between these organization instances seemed to cause this error. When the user wanted to re-install the App for Outlook, they could not do so because it was missing under the ‘Manage Add-ins’ page.

In a previous blog, I have outlined troubleshooting tips with synchronization issues with the Dynamics 365 for Outlook. One of the methods outlined was uninstalling the App for Outlook. To remove the Dynamics 365 App for Outlook you needed to select the ‘Dynamics 365’ Add-in and click the ‘Uninstall’ (‘-‘ or minus icon) button. This cannot obviously be done in this scenario if the Dynamics 365 Add-in cannot be found.

To fix this issue, go to Dynamics 365, click Settings (the cog icon) and click ‘Apps for Dynamics 365’:

In the ‘Apps for Microsoft Dynamics 365’ landing page, click the ‘Re-add the app’ link button under the Microsoft Dynamics 365 App for Outlook section:

To ensure that the changes have been applied through, you’d want to restart Outlook by closing all opened Outlook windows, as well as refreshing browser when viewing the ‘Manage Add-ins’ page in Office 365.

↩ Part 4 - Configure Forms/Views for SLA Instances in Dynamics 365 

In this article I will demonstrate how to configure a Service Level Agreement (SLA) for Opportunity related SLA Instances with multiple SLA Items based on the SLA KPIs previously described in this series.

In this approach the SLA Items will each be based on the same generic SLA KPI but will be individually specific to the Name, renamed to KPI, of the SLA Instance.

Configure an SLA and Related SLA Items for SLA Instances

Navigate to Settings, Service Management, Service Level Agreements.

Add an SLA for SLA Instances. In this approach, even though the name of the SLA is ‘Opportunities SLA’ the entity the SLA is based on is the SLA Instance entity rather than the Opportunity entity.

In this example, before saving the SLA for the first time, I have selected the custom Applicable From field instead of using the standard Created On field for the Applicable From option on the SLA. This is the Date/Time field whose value will be used as the date and time that the related SLA KPIs will be Applicable From. I have chosen to use a custom field instead of the standard Created On field because this provides some flexibility around when and how this field is populated and the date and time this field is populated with.

Create the following SLA Item for the First Response By SLA KPI. Here the selected SLA KPI is SLA KPI. The Name of the SLA Item is First Response By.

This SLA Item is applicable to SLA KPI Instances where the KPI field on the SLA Instance equals First Response By. These SLA KPI Instances will be created when the Opportunity is created. The Applicable From date/time on the SLA KPI Instance will match the Opportunity Created On date and time. In this approach, it is the Applicable When clause, rather than the SLA KPI option, that makes this SLA Item specific to the First Response By SLA KPI.

The Success Criteria for this SLA Item is that the First Response has been Sent to the Customer as indicated by the Quote Sent date/time field on the Opportunity Contains Data.

Create the following SLA Item for the First Response After Quote Accepted By SLA KPI. Here the selected SLA KPI is SLA KPI. The Name of the SLA Item is First Response After Quote Accepted By.

This SLA Item is applicable to SLA KPI Instances where the SLA KPI field on the SLA Instance equals First Response After Quote Accepted By. These SLA KPI Instances are created when the Quote Accepted By date/time field on the Opportunity has been set indicating that the Quote has been accepted by the Customer. The Applicable From date/time on the SLA KPI Instance will match the Opportunity Quote Accepted date and time. In this approach, it is the Applicable When clause, rather than the SLA KPI option, that makes this SLA Item specific to the First Response After Quote Accepted By SLA KPI.

The Success Criteria for this SLA Item is that the First Response After Quote Accepted has been completed as indicated by the First Response After Quote Accepted date/time field on the Opportunity Contains Data.

Create the following SLA Item for the Order Sent By SLA KPI. Here the selected SLA KPI is SLA KPI. The Name of the SLA Item is Order Sent By.

This SLA Item is applicable to SLA KPI Instances where the SLA KPI field on the SLA Instance equals Order Sent By. These SLA KPI Instances are created when the Quote Accepted By date/time field on the Opportunity has been set indicating that the Quote has been accepted by the Customer. The Applicable From date/time on the SLA KPI Instance will match the Opportunity Quote Accepted date and time. In this approach, it is the Applicable When clause, rather than the SLA KPI option, that makes this SLA Item specific to the Order Sent By SLA KPI.

The Success Criteria for this SLA Item is that the Order has been Sent as indicated by the Order Sent date/time field on the Opportunity Contains Data.

Activate the SLA.

Optionally, set the SLA as the Default SLA. If not set as the Default SLA you can use an automated or manual process to assign this SLA to an SLA Instance when required.

The following image shows the activated SLA for SLA Instances and its related SLA Items. In this approach each SLA Item is based on the same generic SLA KPI. Each of these SLA KPIs are Applicable From the date and time value of the Application From field on the SLA Instance. However, the Name of each SLA Instance is used to denote the SLA KPI and the Applicable From date and time on each SLA KPI instance may be different to that used by other SLA KPIs for the same Opportunity.

In my next article I will describe some business logic that needs to be implemented for Opportunities and SLA Instances for the effective operation of this SLA.

Dynamics 365 v9 comes with improved Advanced Find where we can retrieve the records with no child record. However, due to Advanced Find limitations in Dynamics 365 v8 we do not have the ability to run such a query.

Dynamics 365 Version 9

The Advanced Find query below shows how we can select Account records without any child Contact records in Dynamics 365 v9.

Running this query will return results if there are Account records with no association with a Contact records through Company Name field. Such as the one below.

This is a nice feature and allows you to get a better grasp on your business.

Dynamics 365 Version 8

Dynamics 365 v8 doesn’t have the ability to do this in Advanced Find, so we need to look at other methods. The following example shows how to achieve a similar result, using third-party tools such as FetchXML Builder in the XrmToolBox. Note that this approach is done outside of Dynamics 365, so your users are unable to run the query within the application itself.

We can use following FetchXML query to retrieve Account records with no Contact child record. I wanted to see only Account Name column in the results.

Then I ran my query in FetchXML Builder by clicking on OK followed by Execute.

The following screenshot shows the result of this query.

We can double click on the records and it will open the record in the browser too, which is handy if you want to view the record in Dynamics 365.

↩ Part 5 - Configure Multiple SLAs with SLA Instance in Dynamics 365

In this article I will describe some business logic that needs to be implemented for Opportunities and SLA Instances for the effective operation of the Opportunity related SLA Instances related SLA described in this series.

Configure Opportunity and SLA Instance Business Logic

For this scenario you will also need to implement manual or automated processes to perform the following steps on the Opportunity:

• •Create an Opportunity related SLA Instance with the KPI set to ‘First Response By’ and Applicable From date/time set to the Created On date/time of the Opportunity. Assign the Opportunity SLA to this SLA Instance. This will trigger the start of the First Response By SLA KPI based on the name of the SLA Instance, i.e. ‘First Response By’.
  
  
• •Set the Quote Sent date/time on the Opportunity when the Quote is sent to the Customer. This is the Success Criteria for the First Response By SLA KPI.
  
  
• •Set the Quote Accepted date/time on the Opportunity when the Customer accepts the Quote.
  
  
• •Create an Opportunity related SLA Instance with the KPI set to ‘First Response After Quote Accepted By’ and Applicable From set to the Quote Accepted date/time of the Opportunity. Assign the Opportunity SLA to this SLA Instance. This will trigger the start of the First Response After Quote Accepted By SLA KPI based on the name of the SLA Instance; i.e. ‘First Response After Quote Accepted By’.
  
  
• •Create an Opportunity related SLA Instance with the KPI set to ‘Order Sent By’ and Applicable From set to the Quote Accepted date/time of the Opportunity. Assign the Opportunity SLA to this SLA Instance. This will trigger the start of the Order Sent By SLA KPI based on the name of the SLA Instance; i.e. ‘Order Sent By’.
  
  
• •Set the First Response After Quote Accepted date/time when the Customer is contacted after the Quote was Accepted. This is the Success Criteria for the First Response After Quote Accepted By SLA KPI.
  
  
• •Set the Order Sent date/time when the Order is sent to the Store. This is the Success Criteria for the Order Sent By SLA KPI.
  
  

In my next, final article in this series I will describe how I tested the SLA and demonstrate the results of a basic test.

DocumentsCorePack is an add-on for document generation and management based on Dynamics 365 data.  It uses XML like the out of the box Word Templates but has more functionality such as combining with workflows to produce documents automatically, sending documents via email automatically, producing pdfs and saving documents to SharePoint.  In this blog, I will share some tips on using some of the more advanced functionality.

Additional Relationships

By default, when you select the record type you want the document generated from, all the fields on that record and all the fields from any look up on that record are loaded so you can use them in the template.  DCP also allows template designers to define Additional Relationships to pull other data into the template – this can be based on any Dynamics 365 relationship to the record type you are using and records related to those records and so on.   This can be used to filter records based on values of another record.  For example, you need to do a new invoice template that groups and totals sections based on an attribute of the product.

TIP:  When you add the filtering relationship, don’t forget to change the Type of Relationship to Inner.  This defaults to Outer which doesn‘t help as the filter is not applied.

Identifying Merge Fields

When you create an Additional Relationship, you can give it a name but this name doesn’t show on the merged fields in the template.  So, naming the relationship doesn’t help if you need to go back and change it or check how it has been set up. 

TIP:  Click on the DCP Ribbon Field Properties function – this will show the name of the Table shown in the Additional Relationships drop down.

Aggregated Relationships

DCP can aggregate data when you create an Additional Relationship.  This can come in handy if, for example, you wanted to add a statement to the invoice based on what is outstanding as you can use this total in combination with a Word conditional statement. 

TIP:   Use the Result tab on the Additional Relationship to check the format of the aggregated result because the Word Conditional Statement won’t work if the Criteria is in a different format to the result.

There are 2 options to match the formatting:
1. You can format the Criteria in the Conditional Statement to match the calculated result

2. You can change the format of the calculated result to ‘ovalue’ by clicking on the Field Properties and selecting use Internal value

Hope these tips help!

Exploratory testing is an approach that can be taken by a domain experienced tester when there are less documentation/requirements available and there is a limited amount of time for testing. Exploratory testing is not ad hoc testing but a considerate approach to ad hoc testing as documentation is prepared during testing. Using this approach, a tester can create a test charter, set test targets and define a test closure. Business users can be paired up with a tester for testing.

Preparation for Exploratory Testing

Define Test Targets - Primary and Secondary targets can be set prior to test execution.

• Primary Target – Testing can be focused on the main features and high-risk areas.

• Secondary Target – Other features to test such as connectivity to interfaces, verifying the responses, boundary values, decision coverage etc.

Prior to test execution, a tester can think about - test environment, test data, the interface of the product and if there is a need for an additional tester.

Creation of Test Charter

Prepare a test checklist and cover all the areas that will be explored whilst testing and include any relevant information e.g. priority. Get sign off from the client before you start the test execution.

Time Boxing

Time boxing can be very effective during the execution of exploratory testing. Use time boxing to keep focused on the area under test. Ideal uninterrupted time for a time boxed session is between 90 minutes to 2 hours. Record the test data being used and the steps to reproduce a defect.

Basic Checks

Before the execution, check if everything is ready for testing such as the test environment and any relevant equipment which will be needed during execution e.g. printer. If the test environment is not ready or there are connectivity issues then report to your manager and schedule a new test session. Do not waste your testing time trying to fix that issue as we are time boxed.

Knowing When To Stop

• All charters have been completed

• No new interesting defects found – low severity bugs

• Need to decide on the above two points prior to testing

Execution

Execute your tests based on pre-defined targets and test charter. Start with the primary targets and focus on the high severity bugs. Do not lose your focus whilst testing your target as we testers can get distracted by bugs we find and end up testing secondary targets.

Prepare test session sheets to record testing notes during execution. Create notes for the steps to reproduce a bug and record the test data being used.

Sometimes it can be hard to reproduce a bug if the test data and steps to reproduce are not recorded properly.

Closure

Get sign off from the client on the test execution sheet and prepare a defect report.

Test Execution Tips

• A business user is paired up with a tester.

• Use test specification technique e.g. boundary values and decision tables.

• Record your test session.

• Test towards your test targets.

• Keep notes of test data used.

• Keep notes of defects identified.

• Raise defects at the end of a test session when all charters are completed

• If testing is finished before time:

• - create new targets
• - proceed with testing

• If you did not achieve your test target on time:

• - plan a new test session
• - if failure to achieve the test target was due to usability issues in the software, report it to your manager.

Happy testing!
*Image from https://khurrambhattidotcom.files.wordpress.com/2015/10/treasure-map-153425_12801.png

When implementing a Microsoft Dynamics CRM upgrade from on-premise to online, you may encounter unexpected business process errors when exporting an already upgraded CRM solution to import into Dynamics 365 online. The error dialog box won't provide you any log file or any trace of the broken item. To find the root cause of the item, please follow the below steps:

Investigate the Event Viewer in the on-premise environment to find the description of the error. You’ll find the broken resource in the data description, as per the image below:

In this case, the solution couldn’t export web resources.

After you have identified the component causing the problem, you’ll then need to establish the corrupted items by removing them one by one from your solution and exporting it. Once you have the broken item that was causing the problem, you can further examine or recreate them before adding them back to your unmanaged solution.

If you have Windows 10 then chances are that you also have Cortana, which is an Artificial Intelligence Personal Assistant. Cortana can perform many tasks like creating reminders, searching online with Bing, tracking flights, etc. This can all be done from the start menu using either your voice or inputting text.

One interesting feature with Cortana is the ability to connect it to your office 365 account. This gives you access to your Office 365 applications and data, including your Outlook emails and appointments all from your start menu.

Before connecting Cortana to Office 365, you’ll need to check if your organization has enabled Cortana. This step requires an Office 365 Administrator so if you don’t have this level of authentication then you would need to find someone in your organization that does. By opening the Office 365 portal, navigating to the Admin area -> Settings -> Services & Add-Ins and then selecting Cortana, you can enable it as seen in the screenshot below.

Next would be to associate Windows 10 your Office 365 account. This step can be skipped if you have this setup already. You can connect the account by navigating to Windows Settings -> Accounts -> Email & app accounts, and then selecting Add an account to log into your Exchange account.

Once this is done you can activate and connect Cortana. First, clicking on the Cortana search bar next to the windows logo will open the Cortana dialog with a home and notebook icon on the left side pane. Selecting the notebook icon will prompt you to sign in, connecting your Microsoft account to Cortana as shown in the screenshot below.

Once you’ve signed in the you’ll see a similar screen to the first screenshot below when you select the notebook icon from now on. To connect Office 365 to Cortana you would first navigate to the Manage Skills tab and select Connected Services. From here you can select Office 365 and you should be prompted to sign into your Office 365 account. Once this has been completed, after a few minutes you should be able to interact with Office 365 from your desktop.

The screenshots below are a quick example of two scenarios where I can take advantage of Cortana and Office 365. In the first screenshot I asked Cortana, “What’s my day like on Friday?”, to which Cortana pulled the appointments from my Calendar and displayed them in the start menu. The second screenshot shows an email I had Cortana create and send to a colleague of mine. The entire process was completed using voice commands and only took a few seconds.

↩ Part 6 - Configure SLA Instance Business Logic in Dynamics 365

In this article, the final article, in this series I will describe how I tested the SLA and demonstrate the results of a basic test.

The results show that although each of the SLA KPIs are started and stopped when required, the Applicable From and Failure Time date and times for each of the SLA KPIs are all accurate because of the fact that these are based on separate SLA Instances with their own Applicable From date and time values.

Test the SLA

In order to execute a simple and repeatable basic test of the SLA described in this series of articles I created a Workflow Process that to perform each of the record steps such as populating the date and time fields used by the SLA, creating the SLA KPI specific SLA Instances and waiting for a pre-set period of time between steps.

The following image shows the First Response By SLA Instance displayed in the SLA Instances subgrid on the Opportunity a short time after the Opportunity has been created and before the Quote Sent date and time has been populated to indicate the Quote has been sent to the Customer. The second image shows the form for the SLA Instance.

At this time this is the only applicable SLA KPI for the Opportunity.

The following image shows the Success of the First Response By SLA KPI as a result of the Quote being sent before the Failure Time for the First Response By SLA KPI has been reached. The second image shows the form for the SLA Instance.

At this time there are no applicable SLA KPIs for the Opportunity.

The following image shows the First Response After Quote Accepted By SLA Instance and the Order Sent By SLA Instance in the SLA Instances subgrid on the Opportunity a short time after the Quote Accepted date and time has been populated to indicate that the Quote has been Accepted by the Customer. The second and third images show the forms for the SLA Instances.

Here we see that the Failure Times for the First Response After Accepted By SLA KPI and the Order Sent By SLA KPI are respectively correctly 1 hour and 2 hours after the Quote Accepted date and time.

The following image shows the Success of the First Response After Quote Accepted By SLA KPI as a result of the Customer being contacted after the Quote has been Accepted before the Failure Time. The second and third images show the forms for the SLA Instances.

This also shows the Send Order By SLA KPI is still active.

The following image shows the Success of the Order Sent By KPI as a result of the Order being Sent before the Failure Time, albeit incorrect Failure Time, for the Order Sent By SLA KPI has been reached.

The following image shows the related SLA Instances for each of these SLA KPIs.

The approach demonstrated in this series shows how multiple SLA KPIs for the same SLA needing to be Applicable From different dates and times can be implemented.

Finally, there are two limitations of this approach. Firstly, the SLA KPI Timers were not directly displayed on the Opportunity Main Form and secondly the SLA KPI Timers cannot be paused based on the Status/Status Reason of the Opportunity. The second issue can be solved by ensuring there are Status/Status Reasons on the SLA Instance that match those on the Opportunity and that there is a process on the Opportunity to ensure that the Status/Status Reason values of the related SLA Instances always match those of the Opportunity.

Recently, while working on an upgrade from Microsoft Dynamics CRM 4.0 to Dynamics 365, I came across the below error while importing the CRM 4.0 organization database into CRM 2011:

The error was resolved by obtaining the errored GUIDs of the workflow instances (system jobs) from the MSCRM error log file. An instance of the affected GUID in the log file is as below:

    
We acquired all the workflow instance GUIDs from the log file and deleted them from the AsyncOperationBase table in the database. The constraints for the WorkflowWaitSubscriptionBase table must be disabled before executing the deletion query. Remember to enable the constraint after.

Warning: Before running the deletion query, please discuss with the business as the system jobs sometimes have business value and therefore have to be stored for a long period. In our case, the affected workflow instances were created a few years back and were set on the 'Waiting' status while it's regarding object was set to 'Completed' and thus, we decided to delete those.
 
Please note that this is an unsupported fix but will let you proceed with the import to the CRM 2011 organization, moving you forward towards your upgrade to Dynamics 365.

SharePoint is a fantastic way to store documents and other files related to records in Dynamics 365. For one thing, the pricing for using storage in SharePoint is next to nothing compared to the price for the same amount of storage if purchased as database storage for Dynamics 365. Which is no surprise, considering documents in D365 are stored as attachments on notes or emails.

Dynamics 365 does come with a SharePoint integration system out of the box, and for the most part, it’s great. There are a few things that we have come across that have often been issues for people, namely:

• •  Document Locations are not automatically created for records in Dynamics 365.
• •  Folders for records in SharePoint are automatically suffixed with the GUID for the record in CRM, which while helpful for ensuring that only unique folders are created in SharePoint, is ugly and unhelpful when attempting to find a record’s folder through the SharePoint interface.
• •  It’s not possible to specify a set of child folders that should be created for a record when a folder is created for that record in SharePoint.

I’ve recently been working with a product called Microsoft Flow. This is a Microsoft product aimed at not only replacing the existing workflow system for Dynamics 365, but providing the means to automate tasks across a myriad of different systems.

To that end, Microsoft has provided a series of built in ‘Connectors’ that allow for connecting to and performing a predefined set of operations for a vast number of common applications.

I’ve set up a sample Flow that aims to resolve a number of the issues that I mentioned above.

When a record of a specified type is created in CRM, the flow simply sends a folder create API request to the SharePoint API to create each of the required folders for the record, and then creates a Document Location for the record in CRM also, completing the cycle and ensuring that the folder structure is consistent with how the OOTB CRM document integration functions.

The method that is used to create the SharePoint folders is this (in this example for the contact entity):

Data variables can be pulled through from other records in the process, such as the ‘Full Name’ of a contact.

Child folders can also be created in much the same manner:

Like this, we can also create child folders for records that are created in CRM. We can then get a folder structure that ends up something like the following:

• •  Contact
       o John Doe
           ► Folder 1
           ► Folder 2

The complete flow is very simple and looks like this:

Where the last two steps retrieve the parent document location for the target entity (in this case ‘contact’), and then creates a child document location in CRM for that entity.

This is just a trivial example of how flow can be used to automate some SharePoint processes and help to shorten the amount of time you spend on trivial tasks such as creating folders in SharePoint.