Update to the Unified Interface in the October 2018 Release

Microsoft product team just shared the latest update for Unified Interface in the October 2018 release. This is important especially for those who have started embracing Unifed Interface in their organisations. Note: These Unified Interface updates were not highlighted in the October Release Notes and there is no official article/documentation that stating this yet.

Overall, the update is to address the feedback around the usability and adoption of Unified Interface, primarily around the navigation and colour scheme. To keep in mind, this update is going to be automatically applied to the organisations with v.9 onwards, without the “Opt-In” feature (Related to the quite recent announcement from Microsoft about the continuous update of Dynamics 365). It means if your organisation has embraced the Unified Interface, there might be a slight change to the training material (if any) and preparing communications to the end users so that they are aware of this UI/UX change to the Unified Interface.

The changes are as follow:

Before

thumbnail_image001.png

After

thumbnail_image002.png

Sitemap changes:

  • Site map will be expanded by default, with the option to collapse, to improve user recall and learning.
  • Simplified IA: MRU (recent) and favorites (pinned) moved to top level, always visible. No more entity level MRU.
  • No more tabbed sitemap. Bottom flyout used to select areas. To reduce icon overload, colorized tiles replaced area icons.
  • New color scheme (black on gray) to improve navigation discovery.

Commanding changes:

  • Dark text on light background to group commanding with the content area it effects
  • New colored icons and hover effect distinguish different commands and highlights interactive regions

Affected viewport width
These changes are aimed at improving user experience for desktop browser users at widths above 480.

Advertisements

Leveraging Microsoft Flow to be your API Engine – Low Code Approach

Recently I’ve been experimenting with Microsoft Flow and its counterpart, Logic Apps. A thing that I noticed could become a game changer in designing a business solution these days is that Microsoft Flow can be turned into an API engine. In my example, I’m going to create a very simple API to send a message to my Skype for Business and reply back with the response whether the API call is successful or not.

The first step is by registering the HTTP Request trigger in the Flow step:

HTTP_Request_Trigger.png

As any typical API, you will need to specify the data payload. To generate the payload schema, we can use the “Use sample payload to generate schema”. I’m going to use a simple payload to send the message:

{
      “message”:”payload for skype”
}
Payload_generator.png
Once generated, this will create the schema for you
HTTP_Request_Trigger_with_schema.png
To ensure that the payload schema is validated on the HTTP request by clicking the Settings option:
Settings.png
And turn the Schema Validation to On
Schema_Validation_On.png
The next step is to register the action that you would like to perform (you could be creative here with the available connectors for Microsoft Flow or you can come up with your custom connector).
In my sample, I’m going to add the Skype for Business action: Send Instant Message
Send_skype_message.png
As any typical API, we will need to provide the response appropriately. In this example, I’ll just implement the success response. Exception handling will be discussed on a separate blog post.
response.png
Once finished, save the flow and the HTTP Request step will generate the API endpoint:
endpoint.PNG
To test the endpoint, you could simply use Postman (or any tools to stimulate HTTP request) to trigger it:
Postman.png
And here’s the result:
Skype.png
Skype2.png

Conclusion

To create a low-code API is now become very simple with Microsoft Flow. With the available connectors and actions, workflow-based API can be achieved in configurations!

Business Apps. October ’18 Release Highlights

Microsoft just announced the October’18 Release Notes from the last week’s Business Application Summit conference at Seattle. The first question that might come up is: Why October, aren’t we still in July and October is still 3 months away? The answer is in response to the recent blog announcement about the way Microsoft Dynamics 365 will be updated: https://cloudblogs.microsoft.com/dynamics365/2018/07/06/modernizing-the-way-we-update-dynamics-365/. The release notes are made available upfront to allow customers/partners to be familiar to what is coming and plan ahead with the updates.

Now, the official article of the release notes can be viewed here and the actual release notes can be downloaded here. So, after spending the weekend of reading the 239 pages of the release notes I would like to list the highlights of this updates, in particular to the Dynamics 365 CE, Flow and PowerApps. Sorry, ERP-counterpart of the Dynamics 365 family, and Power BI, I’m not the expert on that.

Release_notes.png

So, without further ado, here are the highlights of this October update from my perspective.

Dynamics 365 for Sales

  • Playbook – Seems to be a useful feature, if this can be extensible
  • Microsoft Teams integration!
  • Dynamics 365 AI for Sales Rep… oh WOW!

Dynamics 365 for Service

  • Omni-channel engagement hub
  • Channel Integration Framework – aka bring your own channel
  • BYOB – Bring your own Bot!

Dynamics 365 for Marketing

  • Segmentation enhancement – more operators and hoping for the performance is really bumped up
  • Custom analytics – the current release of Dynamics 365 for Marketing only provides the “Insights” that come from the OOTB package, with this Custom analytics enhancement, really hope that we can create tailored insights, and seems it will open up Power BI reporting

Dynamics 365 Portal

  • Portal Config migration – schema is now going to be provided
  • Embed Power BI on Portal!
  • SharePoint Integration is back!! – oh wait…

PSA

  • Adjustments to approved items! – my wish-list is apparently being implemented 😉

PowerApps & the D365 Platform

  • Embedded canvas app on D365/Model-Driven PowerApps
  • Choose your own size app – closer to the “Pixel-Perfect” slogan
  • Create Canvas Apps with responsive layout – finally!
  • More “integrated” look of Model-Driven PowerApps – within PowerApps studio, instead of the “jumping” experience with the Dynamics 365 CE
  • Improved ALM – looking forward to this!
  • Dependent Option Set – doesn’t tell whether this is for Canvas App only or for Model-Driven Apps as well? If yes, this is awesome!
  • Solution checker – this features from high-level seems to be awesome. Similar to the reports that the PFE guys used to produce 😉
  • Missing features like advanced find, merge records, run reports, run workflows and bulk edit are available in UCI (Model Driven PowerApps)

Microsoft Flow

  • Design Microsoft Flow using Visio – yay! Caveat: need Visio Online Plan 2.

What to expect?

With the above highlights and referring to the “caveat” of the release notes: “Features Releasing from October 2018 through March 2019”, all we can do is to wait and see the update waves to land 😉

Troubleshooting: “There is no active transaction” Error.

Today I encountered a very weird error when I’m working with my team to create a very simple workflow, on a status update, if the status is equal to a specific status, create a task that is assigned to a specific team. However, we can’t proceed due to a very strange reason:

Weird_Error.png

This is the error message:

“There is no active transaction. This error is usually caused by custom plug-ins that ignore errors from service calls and continue processing.”

So, I googled it to find the similar error. Based on a past post by Aileen: http://missdynamicscrm.blogspot.com/2015/10/crm-error-there-is-no-active-transaction-crm-error-plugin.html

We have tried checking the suggested approach by her:

What to Check

So, if you find this error, please check:

– Whether you have custom plugin/custom workflow active triggered
– Whether you put skipping the error that will have impact to the CRM process, it is not possible
– Actually you better to log the error
– Because you won’t know what it is
– This is not your logic wrong in your custom plugin
– This just you need to fix why CRM cannot proceed?
– Is that because your user/team does not have privilege or you missed some parameters required
– This error might happen like for Assignment, Lead Qualification, Quote creation, etc

However, no luck 😦

And we also come across this forum discussion: https://community.dynamics.com/crm/f/117/t/138785?pi61802=2#responses

where some people are mentioning about an issue with ActivityFeeds plugins, again no luck, as we can’t find the specific ActivityFeeds plugins registered.

So, as the usual troubleshooting technique of elimination process, we tried to remove 1-by-1 the workflow mapping, and we found the culprit. Apparently, it’s on the mapping of record owner in the Create Task step. For some reason, if we set the owner on the creation of the task, it keeps throwing the error. So, we split the owner assignment to a separate step to assign the record to the team. Something like:

Weird_Error2.png

And it solves our misleading “Custom Plugin” issue.

 

HTH!

 

TIL: Do not use ExecuteMultipleRequest in Dynamics 365 Plugins/CWA

Today I learned a new thing about ExecuteMultipleRequest within Dynamics 365 plugins and/or custom workflow activities. The following article: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/guidance/server/avoid-batch-requests-plugin suggested that we should avoid any usage of Batch Request in server-side codes.

Background story

My colleague reported that when he is using ExecuteMultipleRequest within the plugin, it is throwing an SQL Timeout error, while he changed it to the single request model, the plugin runs fine.

In the past, I always consider it as the go-to model, when I need to perform multiple requests like creating/updating multiple records. And I used to use this ExecuteMultipleRequest to log exceptions to Dynamics 365 records in the past (according to this MSDN article: https://msdn.microsoft.com/en-au/library/jj863631.aspx).

msdn.png

The Truth

Now I learned that ExecuteMultipleRequest is not designed to be used within server-side codes such as Plugins and CWA. Reason:

guidance.png

The design of batch pattern is to reduce the lags due to the network latency (the application is performing HTTP request to the Dynamics 365 API). Where having the code running on the “same” network is defeating the purpose of the design.

Another reason:

reason_2.png

There is a throttling limit on the batch pattern, by using the batch request in plugins, it is unnecessarily reducing the available “slot” for the concurrent bulk request to run.

Final Remarks:

remarks.png

HTH!

Microsoft Flow: Creating Dynamics 365 Scheduled Report – Low Code Approach

Recently I’ve been exploring the power of Microsoft Business Application Platform. One of the most common requirements that I think we can solve in the Low Code Approach is the scheduled report.

For this example, I’m going to use this example user story to describe the scheduled report requirement: As a sales manager, I want to receive a daily digest of the new opportunities, so that I have the visibility of new opportunities in my organisation.

Before thinking about the solution, we might need to look at the platform that we are working on right now. Microsoft Business Application Platform, where Dynamics 365 plays an integral part in it, comes with Microsoft Flow that has numerous connectors available. This opens up a very broad capability in building the business workflow.

So, without further ado, here is my “Low-Code” approach generating the scheduled report (if you want the more complex one using SSRS, Bob Guidinger, has the solution here).

The first step in the Flow is to set the schedule:

Recurrence_Step.png

Next, we need to construct the filter for the Get List of Records from Dynamics 365 oData query, to build it I’m using Jason Lattimer’s CRM Rest Builder 

Filter_Builder.png

Once the query is generated, copy the filter as the base to be put in Flow

Filter-Copy.png

To get the created on = yesterday, we could use the Flow Built-In Formula/Expression:

List_Records.png

You also could try the query whether it’s successful or not by running the Test process on Flow

Test_Result.png

This will need a bit of Dev knowledge to understand the JSON output of the list records, but we can confirm that it is returning the list correctly or not

Testing_on_the_List_Records.png

Once confirmed, then we can construct the HTML table for the email body using the Create HTML Table action on Flow and to some field mapping.

Create_HTML_Table.png

And then send the email action:

Send_email_v1.png

Make sure that to select the Is HTML to Yes, otherwise, the HTML tags will be rendered as literal text

Is_HTML.png

This will produce a very basic email, that tick the box of the requirement, but not pretty

V1_Email.png

So, to make it more appealing, I’m adding the “Low-Code” CSS to style the table using the compose action before sending the file

CSS_Prettify.png

Attribution: CSS is a copy from w3schools: https://www.w3schools.com/css/tryit.asp?filename=trycss_table_fancy

Now with the CSS, the table is looking more appealing

CSS_Applied.png

Another ask, can we also have this table/report as HTML. The answer is Yes. Microsoft Flow has connectors to convert HTML to PDF via 3rd party service such as Muhimbi PDF or Plumsail Documents (which requires subscription/license)

SaveToPDF.png

The quick and dirty option to save to PDF is via OneDrive actions, by creating the HTML and Convert the file to PDF.

OneDrive_Option.png

Typically you could create a folder in OneDrive to store the report temporarily and do periodic clean-up.

Then this can be added to the email as an attachment:

Add_Email_Attachment.png

Which produces the email with the PDF attachment:

Email_With_Attachment.png

And the PDF file opened with PDF reader:

Open_in_PDF.png

My Final Flow is something like this:

Final_Flow.png

 

HTH! Happy Flow-ing!

Gotcha: Don’t Use Nested Security Group

Some time ago, I published a blog post about a tip about using Security Group in Dynamics 365 Online Deployment. And I’ve got a feedback from one of my colleagues where the security group is not allocating the users properly. So, I investigated the behaviour with my colleague and found an interesting setup.

TL;DR; version: Do not use Nested Security Group, as Dynamics 365 would not honour it.

The Long Version

So, I noticed in my colleague’s environment they have set up nested security group. To explain, I’m going to “replicate” the scenario in my environment.

I have set up my sandbox environment to use “Dynamics Sandbox” security group as follow:

Sandbox Security Group.png

And the Dynamics Sandbox security group has membership as below:

Parent_Group.png

“Dynamics Test” there is the child group that I have setup with the following members:

Child Group.png

Normally, When I have a nested group like that. I would expect Test User 2 – 5 will also be included in the Enabled Users list. However, this is the result:

Actual.png

To ensure the rest of the users are synced to Dynamics 365 the group must be flattened:

Flatten_Model.png

Then, you’ll be able to see them in Dynamics 365.

Actual-flatten.png

I have confirmed the behaviour with the Microsoft support, that nested group is not supported at this moment.

Hope this helps!