Dynamics CRM for IOT - Hello Intelligent Big Data - Connected Field Service

Dynamics have connected with IoT with Azure, enhancing the number of possible real world implementations. Dynamics 365 Field Service is a best avenue to take advantage of IoT technology for industrial benefits. 

With the massive amounts of data available in field service industry collected via IoT devices, D365 Field Service can move forward in taking sound management decisions using real time data. D365 Field Service is the best platform to manage small to large scale service industry requirements.

Field Service under D365 Umbrella

• To start with Dynamics 365 is a collection of intelligent business applications on a common platform, And from these, Field Service is a very popular application among manufacturing and service industries. It targets in helping organizations to deliver outstanding onsite/offsite services to their  customers. 

 

• Field service, extends Microsoft Dynamics 365 to provide an end to end solution to manage field agent activities

• In general field service is all about completing a work order for the customer fulfilling required resources and services.
  So general field service starts when a customer inquire about a service, then it manages the entire service providing process.
• It does resource management, inventory management, scheduling, mobile agent handling and Analytics etc.

Internet of Things (IoT)

• Kevin Ashton (researcher in RFID and sensor technology),  is known for coining the term “the Internet of Things” to describe a system where the Internet is connected to the physical world via ubiquitous sensors.
• Describes IoT as a network of “eyes and ears” for computers: with Internet of Things, computers can sense things for themselves (Keyboard data entry era is over)

• One of the first examples of an Internet of Things is from the early 1980s, which was a Coca Cola machine, at Melon University. Local programmers have connected it to internet to see if there was a cool drink available, before making the trip to the machine.
• In the chart you can see how much of IoT devices are proactively used in various industries. And it is expected to have over 267 billion USD worth IoT devices  by 2020.

Field Service and IoT

Field Service is one of the very first industries to use IoT in Commercial use

• The field service industry has evolved alongside IoT. And it has established interoperability across devices, applications, and platforms.
• Reduced Costs - Preventing breakdowns and reducing downtime. Efficient Use Of Resources.
• Best-of-Breed Solutions - IoT encourages businesses to use software applications and hardware devices are specific to their needs.
• Customer Satisfaction – The ability to take actions even before customer notice it and make a service call. Proactive services.

The challenge, is how to utilize the massive amount of data generated through IoT devices on the field, to improve operations and customer satisfaction.

D365 Traditional Field Service

• In a traditional field service organization, when customer gets a problem they calls to arrange a service agent to get it fixed. (Ref: https://www.naviworld-asia.com)

D365 Connected Field Service (CFS)

• Connected Field Service - Detect, troubleshoot, and resolve issues remotely so a technician is dispatched only when necessary. Know about problems and solve them Just-In-Time before customers are affected using IoT Technology.

• Connected Field Service eliminates the customer concern by attempting to complete self-healing repairs remotely before sending out a technician

• Organizations can benefit from “just-in-time” preventative maintenance instead of scheduled preventative because Connected Field Service can look at the actual consumption of a part and send out alerts when the part needs to be changed or cleaned. 

CFS Path to Implementation

Basic:

When an anomaly is detected, Field Service automatically creates a work order and dispatches a technician to consider the issue. This level of Connected Field Service takes a proactive approach to improve customer satisfaction by decreasing overall downtime and making repairs before customers become aware of the problem.

Advanced:

When an anomaly is detected, Field Service asks the device to try to fix itself with a single, self healing command. If that command doesn’t work, then Field Service automatically creates a work order and schedules a technician. Organizations experience improved customer satisfaction levels and gain greater productivity because fewer technicians are dispatched when devices can self-heal.

Expert:

At this level, Field Service initiates a multi-step workflow when an anomaly is detected. This attempts to fix the device in as many ways possible without requiring human intervention. This level maximizes customer satisfaction and resource productivity because a technician is only dispatched when all other possibilities are exhausted.

CFS Implementation

There are two offerings you can use to connect IoT-enabled devices into the Field Service solution:

•Connected Field Service for Azure IoT Central (SaaS)

•Connected Field Service for Azure IoT Hub (PaaS)

Azure IoT Central

Azure IoT Central is a fully managed global IoT SaaS (software-as-a-service) solution that makes it easy to connect, monitor, and manage IoT assets at scale.

Objective:  Connect a Physical Device to IoT Cloud and then Allow Dynamics 365 Field Service to Act        upon the sensor data.

• Azure IoT Central can send information about device anomalies to Connected FieldService (as an IoT Alert) for diagnosis.
• Connected Field Service can create cases or work orders triggered from device anomalies.
• Connected Field Service can schedule technicians for inspection to prevent the downtime incidents.

• Azure IoT Central enables builders to configure rules and actions. Based on those actions, IoT alerts will be created in Connected Field Service. Also, based on service activities in Connected Field Service, information can be sent back to Azure IoT Central. This is accomplished by using Microsoft Flow, a SaaS offering for automating workflows across applications and services.

Azure IoT Hub

Objective:  Connect a Physical Device to IoT Cloud and then Allow Dynamics 365 Field Service to Act upon the sensor data.

• IoT Hub is a managed service, hosted in the cloud, that acts as a central message hub for bi-directional communication between your IoT application and the devices it manages.

• IoT Hub supports multiple messaging patterns to control your devices from the cloud, such as
• Device-to-cloud Telemetry
• File Upload From Devices
• Request-reply Methods

• IoT Hub gives you a secure communication channel for your devices to send data

• Built-in message routing functionality gives you flexibility to set up automatic rules-based message fan-out (Use message routing to control where your hub sends device telemetry)

• Integration from IoT Hub to other Azure services available to build end-to-end solutions
• Azure Event Grid
• Azure Logic Apps
• Azure Machine Learning
• Azure Stream Analytics

• IoT Hub can be used to build IoT solutions with reliable and secure communications between millions of IoT devices and a cloud-hosted solution back-end. You can connect virtually any device to IoT Hub.

Below is a step wise guideline for setting IoT Hub for Field Service

1.  Apps Automatically created in IoT Hub

2. Add Connected Field Service in D365 CRM Instance Manage

      

   

 3. Connect your IoT device to Internet

4. Use Logic app in IoT hub to create records (anything you want as output) for IoT feeds

5. You will get records created in D365 Field Service according to the IoT feeds

Dynamics 365 Workflow Scope - User or Organization

Hello mobile world,

Now this is something I didn't pay much attention until QA reported a bug. Workflow doesn't get fired when record create is synced using CRM Resco Mobile.

Workflow scope defines the level of records the workflow will be triggered on. This is something you must pay attention to as  much as the user role security. When you create a workflow in Dynamics 365 V9, by default it's set to User Scope. Workflows with user scope will trigger only for the records that user is privileged to. 

1. User

Choosing this scope means the workflow will run only on the records owned by the same user as the workflow user. This is more like a private workflow of the user.

2. Business Unit

This means the workflow will run on all records owned by the users of the same business unit as the workflow user. 

3. Parent: Child Business Unit

With this, the workflow will run on the records owned by the users of the same business unit as the workflow user as well as any child business units. 

4. Organization

The workflow will run on records owned by any user in CRM. Since it will trigger for all records, organization scope is the most used scope option.

For automatically triggered workflows, they are executed in the security context of the workflow process’s owner and not according to the user who performed the action on the record, that might trigger the workflow (if workflow scope supports).

No matter which Administrative privileges you have on your CRM User, you won't be able to trigger a workflow set to User Scope and Owned by other user. :P

And also this scope applies to all the records and logic in the workflow steps too. For example, imagine you triggered the workflow (Scope = user) on Contact record update (which your user owns) and then you are going to update the Primary Account of the Contact. To update, your User should own the relevant Account record too. Otherwise the workflow will give error.

Now, for the issue I got with CRM Resco Mobile, I had to set the workflow Scope to Organization, to allow it to trigger on Mobile data sync event.

Hope this will be useful to somebody.

Closer look into Custom Actions - CodedActivity or Plugin Step ?

Hello Complicated World,

Actions, which was introduced in 2013 now have been around for a very long time. Action is definitely a process that allows a non developer user to create and add some logic (child steps) same as Workflows. Yet in the hand of a CRM developer Actions can do magics ;) .

To list down the differences, 

1. Actions can only be called or triggered by a custom code, a client side (JavaScript call) or a server side code (inside C# plugin or custom workflow) call. 
2. Actions can support for Global entity, meaning that Actions can stay unbound to any specific entity and serve it's purpose at any time it get's called. 
3. When calling the action, we can pass input parameters to the actions and retrieve output parameters on the successcallback.

Now the important questions, what does Custom Actions mean?

When it comes to  CRM customization, we mainly consider Custom Plugins inherited from IPlugin and Custom Workflows inherited from System.Activities.CodeActivity, where both comes with custom C# dlls to register.

Custom Actions don't have such code implementations. Custom Actions means simply creating new Actions in CRM in-addition to OOB Actions provided by default.

Yet there are two ways to extend Actions beyond CRM by triggering custom C# code. The selection is either to, 

• Use Custom Action name as a SDK Message to trigger a Plugin step
• Add custom workflow as a step inside Custom Action

Use Custom Action name as a SDK Message to trigger a Plugin step

Simple steps to follow are,

1. Create a new Action Process with input/output parameters and Activate the action

2. Create a new plugin dll project and write a plugin step handler for the action. I am using SDK plugin class implemented by inheriting IPlugin here. You can directly use IPlugin and use execute method.

public class testActionHandler : Plugin { public testActionHandler() : base(typeof(testActionHandler)) { base.RegisteredEvents.Add(new Tuple<int, string, string, Action<LocalPluginContext>>((int)PipelineStage.PostOperation, "tst_testAction", "", new Action<LocalPluginContext>(ExecuteAction))); } private void ExecuteAction(LocalPluginContext obj) { var pluginExecutionContext = localContext.PluginExecutionContext; var inputparam = (string)localContext.PluginExecutionContext.InputParameters["inputarg"]; //your custom code pluginExecutionContext.OutputParameters["outputarg"] = true; } }

3. Register the plugin step inside the custom plugin dll assembly and use Action name as the message name (it should come in the dropdown ;)). 

Now you are good to go and you can call this action from both JavaScript and other plugins and workflows. So the execution order would be,

Action call --> Custom Action Trigger --> Plugin step trigger

Add custom workflow as a step inside Custom Action

This is almost similar to calling custom workflows inside OOB workflow. 

1. Write a CodedActivity class and configure it's input parameters. 

public class testActionHandler : CodeActivity { [Input("inputarg")] public InArgument<string> inputarg { get; set; } [Output("outputarg")] public OutArgument<Boolean> outputarg { get; set; } protected override void Execute(CodeActivityContext executionContext) { ITracingService tracingService = executionContext.GetExtension<ITracingService>(); IWorkflowContext context = executionContext.GetExtension<IWorkflowContext>(); IOrganizationServiceFactory serviceFactory = executionContext.GetExtension<IOrganizationServiceFactory>(); IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId); var inputarg = context.InputParameters["inputarg"]; // your code here var output = true; outputarg.Set(executionContext, output); } }

2. Add a step inside the action and call the registered custom workflow

And now you are done. :)

Okay now the important question, what's best way?

According to my view, best way to extend an Action with C# is to use plugin steps. Reasons behind are, 

• The Action is independent from the plugin steps we create using it. We can delete the plugin steps without affecting the Action. But when you add a custom workflow (CodedActivity) as a step inside Action, you cannot delete the custom workflow without removing it from the Action first.

• It's easy to manage input parameters with plugins, rather than with custom workflows. With custom workflows, sometime resetting input parameters become a hazard as it doesn't get update in CRM UI immediately. 

Adding custom workflow as a step make-sense when you want to re-use an existing workflow. Otherwise you are just increasing dependencies.

Let me know your thoughts on this. :)

Get list of Entities in CRM query by Display Name (CRM bulk update)

Hello World,

MetadataSchema.Entity does not have the Display Name of the Entity in it. To get Display Name of a Entity we have to use MetadataSchema.LocalizedLabel. 

In the bellow query I get the all Entities where Entity Display Name starts from 'Z'.

select distinct e.Name, e.LogicalName, e.OriginalLocalizedName, OptionSetValue.Label
from MetadataSchema.Entity as e inner join
MetadataSchema.LocalizedLabel as OptionSetValue on (e.EntityId = OptionSetValue.ObjectId and
OptionSetValue.ObjectColumnName = 'LocalizedName')
where OptionSetValue.Label like 'Z%'
order by OptionSetValue.Label

With this we can easily get a list of entities and can do other necessary implementations in bulk. 

For example this is a good input to the query in below link,

http://matheeid.blogspot.com/2014/12/bulk-hide-entities-from-advance-find-in.html

Bulk Hide Entities from Advance Find in MS Dynamics CRM

Hello World,

If you are in trouble with unnecessary Entities in your Advance Find (that you created while ago and no longer needed) but you don't want to remove them. And you want to hide them from your customers. And you are too lazy and you want one query that works for all. :)

I was that lazy.

EntityMetadata.IsValidForAdvancedFind Property 

     - Gets or sets whether the entity will be shown in Advanced Find

if IsValidForAdvancedFind = 1 

then referring entity will be shown in Advance Find.

Therefore to hide a entity from Advance Find we can write - 

         update MetadataSchema.Entity

         set IsValidForAdvancedFind = 0

         where  Name = 'EntityName' 

Above will hide the contact  entity for all users  on the advanced.

Then to hide the Entity been displayed under related Entities we can write,

update MetadataSchema.Relationship 

set IsValidForAdvancedFind = 0

where ReferencingEntityId = (select MetadataSchema.Entity.EntityId 

    from MetadataSchema.Entity 

    where Name = 'EntityName') and IsValidForAdvancedFind  = 1)

If you have multiple Entities to update you can easily change the '=' to 'IN' and write all the Entities as a array.

update MetadataSchema.Entity 

set IsValidForAdvancedFind = 0 

where Name IN ('EntityName1', 'EntityName2', ......)

Hope this would be useful

Mathee

When Run CRM  report if you don't get exact page count as below,

You can changes this by changing CRM  report viewer aspx file.

go to 

CRM/CRMWeb/CRMReports/rsviewer/reportviewer.aspx file

and change the below highlighted report control properties by adding PageCountMode="Actual" property.

In default report viwer pageCountMode is Estimate.

</style>
</head>
<body style="<%if (doNotShowBorder) { %> border-style:none;<% } %>">
<div style="height:100%; width:100%; position:absolute">
<form id="form1" runat="server" style="height:100%">
<asp:ScriptManager id="scriptManager"  runat="server" />
<rsweb:ReportViewer id="reportViewer"  runat="server" width="100%" height="100%"/>
</form>
</div>

</body>
</html>




<rsweb:ReportViewer id="reportViewer" PageCountMode="Actual"   runat="server" width="100%" height="100%"/>