Category: PowerApps

Column Comparison is one of the best features that has been recently added to the product.

Column comparison allows us to compare values of 2 different columns in our query be it Fetch XML, Web API, or through SDK API.

Sharing some of the basic examples that we tried using our favorite  FetchXML Builder

• If we run the following query “Find all contact which has the first name equal to the last name”

The result –

• Find all contact where the first name is not equal to last name

The result –

The operators supported are –

• Only 2 columns can be compared.
• Only compatible attribute types can be compared.
• E.g. “Find all contact where the first name is equal to address 1 city”

The result

It works as both are string attributes.

• If we try comparing text field with options set, we will get below error message

• Two option set can be compared as they represent the same type integer

Both having value 1

• Comparing date fields
  

• We are getting the result

• For the lookups, comparing created by and owner id
  

works as expected.

• For the below record we have the First name and job title as null

And here for below record, we have the same value for First Name and Job title.

On running the below query – find all contact where the first name is equal to the job title.

We get only one result. It ignored the blank (null) record.

Get all the details here

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/column-comparison

Hope it helps..

In the previous posts, we learn about provisioning, setting up a live chat, and WhatsApp channel.

In this post, we’d see how to set up an Entity records channel.

Through the Entity records channel, we can route cases as well as other entities to the omnichannel agents.

To enable an entity for Routing, enable Activities and Queues for that entity.

Leave the “Automatically move records to the owner’s default queue …” checkbox unchecked for automatic distribution of records to work.

Inside the Omnichannel Administration app, navigate to Channels à Entity Records to create a new entity record channel.

A default workstream will be created automatically, we can also select an existing workstream.

Click on the Routing Rules tab to define the routing rule.

Add a new rule item i.e. for case type as a problem, route the record to Complaints Queue.

Activate the routing rule created.

Let us create a new case of type problem and apply routing to it.

We can see the records added to open work items for agents to pick as defined in the CDS entity workstream.

We can also set the Work distribution mode to Push that would send the notifications to the agent

To automatically route the record we can use Power Automate to define a flow that calls the Apply Routing Rule action.

Refer below blogs to learn in-depth about the Omnichannel

https://neilparkhurst.com/2020/05/29/omnichannel-for-customer-service-collection/

https://thecrm.ninja/omnichannel-for-dynamics-365/

along with Microsoft Docs

https://docs.microsoft.com/en-us/dynamics365/omnichannel/omnichannel-customer-service-guide

Hope it helps..

In the previous post, we provisioned the Omnichannel for Customer Service and had configured the Chat channel.

In this post, we’d see how to set up the WhatsApp channel (preview)

Within the Omnichannel Administration app, navigate to Channels à WhatsApp and create a new WhatsApp account record.

Provide the required consent

As a first step, let us set up the Twilio sandbox account to be used for WhatsApp channel configuration.

Create Twilio WhatsApp account

https://www.twilio.com/whatsapp

Navigate to console and copy the value of Account SID and AUTH TOKEN

https://www.twilio.com/console

Specify Account SID and Auth token of the Twilio account created in the new WhatsApp channel record.

Saving the record will generate the Twilio inbound URL, copy that URL.

Navigate to Twilio Console à Programmable SMS à WhatsApp and activate the sandbox.

Follow the instructions to configure the sandbox.

On successful confirmation, select Sandbox in the navigation menu and paste the Twilio Inbound URL generated eariler in the “When a message comes in” text box

Back in our WhatsApp channel record, add the sandbox WhatsApp number configured

Specify the Twilio Sandbox WhatsApp number and select the out of the box WhatsApp workstream.

The default WhatsApp workstream

Next click on Validate to check the configuration

With validation successful now we are good to test it.

Send the message to the Twilio sandbox number

The agent will receive the notification from the WhatsApp channel configured.

On accepting the notification, Agent can now communicate with the visitor.

Thus, we saw how seamless it is to configure and get started with WhatsApp channel in Omnichannel for Customer Service.

Refer below blogs to learn in-depth about the Omnichannel

https://neilparkhurst.com/2020/05/29/omnichannel-for-customer-service-collection/

https://thecrm.ninja/omnichannel-for-dynamics-365/

along with Microsoft Docs

https://docs.microsoft.com/en-us/dynamics365/omnichannel/omnichannel-customer-service-guide

Hope it helps..

For one of our projects we are exploring capabilities of Omnichannel.

Below are the steps for provisioning the Omnichannel for Dynamics 365 Customer Service for quick reference.

First, we need to make sure we have the Customer Service Hub already installed.

https://trials.dynamics.com/

Next, we need to have an active subscription of Chat for Dynamics 365 Customer Service or Dynamics 365 Digital Messaging

The other options

https://docs.microsoft.com/en-us/dynamics365/omnichannel/try-channels

Navigate to Microsoft 365 Admin Center

https://admin.microsoft.com/

Select Purchase services
à
Add-ons

Select Dynamics 365 Customer Service Digital Messaging Add-on trial.

And also assign the add-on license to the users who need to work with Omnichannel Service.

Login to Data access consent URL using the Global Tenant Admin account and give the consent.

We’d be presented with the below message.

Login to Dynamics 365 Administration Center and navigate to Applications Tab and click on manage for Omnichannel for Customer Service.

https://admin.powerplatform.microsoft.com/environments

This opens the Manage environment page for Omnichannel.

Click on Add Environment to add the environment.

Here we can select the environment to which we want omnichannel solutions to be configured.

Click on next and we can then add chat as one of the channels.

Click on Next to similarly setup SMS, Social, and Microsoft Teams as the channels.

Click on Finish to start the installation.

It will show the status as Installed after some time. (took around 1 and half hour in our case)

To manage the channels or delete the omnichannel we can use the same Manage option for Omnichannel for Customer Service in the Applications tab within Dynamics 365 Admin Center.

We can use the Delete button to remove the Omnichannel configuration à

We’d also see the Omnichannel Administration and Omnichannel for Customer Service apps in the list of Dynamics 365 Apps.

Get all the details here

https://docs.microsoft.com/en-us/dynamics365/omnichannel/administrator/omnichannel-provision-license

Hope it helps..

We can specify Status Reason Transitions for Case as well as custom entities. Using the status reason dialog box, we can define (filter) which values are available to be set as next status reason.

Let us take a scenario where we have the following values defined for Status Reason for Active State in a custom entity named Test Entity.

Just to keep it simple we have a just on transition defined i.e. from A1 we can only select A2.

So now when a user creates the Test entity record with A1, the only other option user can select is A2.

Now let us try updating it through backend and set value as A3 for the same record with value A1 as status reason. (Here we have used SQL 4 CDS plugin)

Well, it updates the record with value A3 and doesn’t throw any error.

This would make us think that it only works from the client side and will not work from the server side.

Let us now create a workflow to update the value to A3.

Let us update the subject of the record to trigger the workflow for the below record.

Interestingly we get the error and are not able to set it to A3 as expected.

That was with the real-time workflow, for the asynchronous workflow also we get the error.

Let us give it one more try and update it through service.

Through the service call, we can update it.

So basically, the State transition rules will work as expected from user interface and workflows, however, through service we are still able to override it, which we need to be aware of before using this feature.

Hope it helps..

Subject entity \ feature has always been an integral part of Dynamics CRM at least since 3.0.

It gives a nice hierarchical way of organising and maintaining information.

To create or update Subject, navigate to Service Management area.

Similar to Subject entity, Category entity was introduced in CRM 2016 Update 1 (Service Pack 1 – On-Premise).

Navigate to Service Management area, to work with Category entity.

• Can we customize Subject or Category Entity?

We cannot customize Subject. It is available for Case, KB Articles, Product Catalog items and Sales Literature.

We can customize Category Entity.

We can create forms, add fields, views, business rules, dashboards etc.

Can create 1 – N relationship from Category to other entities.

We cannot create N- 1 or N-N relationship.

It has N-N relationship with Knowledge Article entity

• Is category User Owned or Organization Owned entity?
  

User Owned

• How are they rendered inside form?
  

Subject are rendered as tree structure

Category are rendered as lookup

We can also specify Auto-numbering for Categories

• What happens if a delete a Subject or category?
  

Deleting the subject will not delete its child record.

Deleting the category will delete its child record.

• Can we run advanced find on Subject and Categories?
  

We can do it on Categories, not on Subject.

• How does Subject render when used in advanced find filter condition? Tree view?
  

It renders like a lookup

Few considerations while migrating  Subject records

https://crmchap.co.uk/importing-exporting-subject-records-between-dynamics-365-customer-engagement-environments/

Hope it helps..

Recently we had to find out what all Dynamics 365 Apps and Power Platform features are available in our UAE region.

To get these details navigate to

https://dynamics.microsoft.com/en-cy/geographic-availability/

and open the report

Below are the different Products and Geography available.

Below is the report filtered for UAE for Power Platform.

For Dynamics 365 App

Hope it helps..

Let us take a scenario, where a data migration package is running, and it either creates or updates (or deletes) a large number of records into Dynamics 365, and we want to get the count of records created/updated/deleted in the last x hour or so.

With views, we are limited to just 5000 records.

One option is to write the console app having the required QueryExpression or FetchXML condition using the Dynamics 365 SDK to get the count.

We can also make use of SSRS reports here.

Create a report using the report wizard, specify the criteria

In the LayOut fields window, specify Count as the summary type for grouping.

Run the report to get the count.

Another option that we have used the most is to use the FetchXML
Builder plugin to build the query, copy it.

And use it in the FetchXML / View Record Counter plugin of XrmToolBox.

Select the entity, contact, in this case, paste the FetchXML query and click Execute Count.

We will get the count.

Along with FetchXML / View Record Counter we can also use
SQL 4 CDS plugin.

Within the FetchXML builder click on Edit in SQL 4 CDS button.

The result

And now with CDS T-SQL endpoint (preview), we can use SQL Server Management Studio as well to directly write the T-SQL instead of fetch xml

https://nishantrana.me/2020/05/21/setting-up-using-sql-to-query-data-in-dynamics-365-preview/

We can also use the CDS T-SQL endpoint within the SQL 4 CDS Plugin.

https://markcarrington.dev/2020/05/24/sql-4-cds-2-1-0-the-t-sql-edition/

What if we want total record count for an Entity?

Apart from all the methods above,

• we can use Record Counter XrmToolBox Plugin for that

https://www.xrmtoolbox.com/plugins/AndyPopkin.RecordCounter/

• or use RetrieveTotalRecordCountRequest
  

https://dreamingincrm.com/2019/07/22/getting-entity-record-counts/

• or use Count aggregrate function
  

https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2016/developers-guide/gg309565(v=crm.8)?redirectedfrom=MSDN#count

however, it will fail in case of more than 50000 records

‘AggregateQueryRecordLimit exceeded. Cannot perform this operation.’

To increase the limit (on-premise)- https://nishantrana.me/2012/09/06/aggregatequeryrecordlimit-exceeded-cannot-perform-this-operation/

• Will returntotalrecordcount property of FetchXML help ?
  

It will be helpful if total records are less than 5000.

Hope it helps..

We can get the different metrics about the usage of the platform like active user usage, the operation performed, the entity used, plugins and API statics, etc. through Command Data Service Analytics (formerly Organization Insights).

https://admin.powerplatform.microsoft.com/analytics/d365ce

These reports can also be downloaded.

Some of these details can also be captured by enabling Audit user access.

And navigating to Audit Summary View

This view can be filtered to show only the User Access via Web event to get the last logon details for the users.

We can use below FetchXML query to get the same details

<fetch mapping=’logical’ aggregate=’true’ version=’1.0′ >
<entity name=’audit’ >
<attribute name=’createdon’ alias=’LastLoginDate’ aggregate=’max’ />
<filter>
<condition attribute=’operation’ operator=’eq’ value=’4′ />
</filter>
<link-entity name=’systemuser’ from=’systemuserid’ to=’objectid’ alias=’su’ link-type=’inner’ >
<attribute name=’fullname’ alias=’fn’ groupby=’true’ />
<attribute name=’domainname’ alias=’dn’ groupby=’true’ />
<attribute name=’userlicensetype’ alias=’ult’ groupby=’true’ />
<attribute name=’accessmode’ alias=’am’ groupby=’true’ />
<attribute name=’isdisabled’ alias=’id’ groupby=’true’ />
</link-entity>
</entity>
</fetch>

We can also run the following SQL Query (in case of on-premise) to get the details

SELECT su.fullname,
su.domainname,
su.userlicensetype,
su.accessmode,
su.isdisabled,
max(a.createdon) AS LastLoginDate
FROM audit AS a
INNER JOIN
systemuser AS su
ON su.systemuserid = a.objectid
WHERE a.operation = 4
GROUP BY su.fullname, su.domainname, su.userlicensetype, su.accessmode, su.isdisabled;

Now there could be some users who have never accessed the application, to get details of those user we can use the below query

SELECT su.fullname,
su.domainname,
su.userlicensetype,
su.accessmode
FROM systemuser AS su
WHERE su.systemuserid IN (SELECT systemuserid
FROM systemuser
EXCEPT
SELECT DISTINCT objectid
FROM audit
WHERE operation = 4);

We can also use the wonderful User Audit Viewer XrmToolBox Plugin for getting the user audit details.

Can we use the new SQL Data Connection for CDS (preview) to query Audit information ?

We cannot as the Audit Table is not available

Hope it helps..

I was recently watching the FastTrack TechTalks on Data Migration.

https://community.dynamics.com/365/b/techtalks/posts/data-migration-january-16-2018

Below are some of the key points from the session à

Customer 360 View is more often than not, the starting point of the data migration discussions. Storing all the data in Dynamics 365 might not be a good idea as it could impact the performance and more importantly, the storage has a cost associated with it.

Learn more about the storage in Power Platform here

https://docs.microsoft.com/en-us/power-platform/admin/whats-new-storage

Important Considerations as part of the Data Migration Strategy

Data Source

• What is the source of the migration? Is it a single system or multiple systems from which the data needs to be consolidated.
• The appropriate connectors or technology needed to fetch or extract the data from the source system(s). (SQL, File-based, Web Service, etc.)
• Need for a staging database for transformation and cleansing of data before migrating it to Dynamics 365.
• Having a well-defined Dynamics 365 data dictionary and model.

Data Cleansing

• Removal of the old data.
• De-duplicate of the data.
• Checking for null, missing required fields and references.
• Identify and define the uniqueness of the record.
• Need for defining Alternate keys

Data Transformation (mapping with Dynamics 365 entities and fields)

• Transform the data to adapt to the target Dynamics 365 Data model.
• Format and Range of the fields.
• Calculate or combination of different fields.
• Filtering and Enriching of the fields

Mapping OptionSet in KingswaySoft SSIS Integration Toolkit for Dynamics 365

Mapping OptionSet in Scribe Online

Lookup and Cache Transformation component in KingswaySoft SSIS Integration Toolkitfor Dynamics 365

Data Loading

• Is it one-time migration (plus delta load daily) or n times migration
• Based on the time it takes, the batch can run over the weekend or after office hours daily.
• Order of data load – Master \ Configuration Data à Parent records àChild records.
• Use Create or Update whenever possible instead of Upsert.
• For Inactive records, first, we need to create those records as active, associate any child records to it if any, before updating the status of the record.
• Use multithreading and execute multiple requests.
• Figure out the optimum batch size and thread.

Optimum batch size

For Upsert in KingswaySoft SSIS Integration Toolkit for Dynamics 365

For Delete in KingswaySoft SSIS Integration Toolkit for Dynamics 365

Volume

How many records are to be migrated and how much time will it take.

Storage / Scalability

Do we need all the data to be stored in Dynamics 365, or for Customer 365, can we leverage Power BI reports which could pull data from different data sources?

Do we need all the data for all the entities or last x months?

Compliance and regulations

We need to consider what information is allowed to be stored/accessed by the users in Dynamics 365.

Other key points

• Use WebAPI for migration.
• Use Execute Multiple for batch operations.
• Leverage Application User that provides Server to Server authentication.
• To update CreatedOn field use OverriddenCreatedOn field.
• Use Create OnBehalfOf / CallerID for Created By field.
• Map ModifiedBy and ModifiedOn to custom fields for the historical purpose.
• Check for the sequence of the auto-number fields in the entities.
• If possible for improved performance – during migration disable duplicate detection, workflows, plugins, audit, activity feeds, etc.
• Leverage the same location/region for running the package as the Dynamics 365.
• For faster date-time conversions set regional settings to UTC for the service account being used.

Check out the below articles

https://kunaltripathy.com/2019/06/04/dynamics-365-data-migration-demystified-part-i/

• Importing Legacy Users
• Migration Starter Pack for Dynamics 365
• Data migration with XML as a source
• Working with Scribe Online

Hope it helps..

I recently read the kindle version of the book PowerApps Portal Authentication by Debajit Dutta and Chandana Kommuri.

The book covers in detail the different authentication methods available for the PowerApps Portals and also provides detailed instructions to set them up.

The different topics included in the book are

• Local authentication – Self Registrations and Invitations.
• External Authentication – with Google, Facebook, LinkedIn, Azure Active Directory (B2C and B2B)

This is the first and the only book in the market on PowerApps Portals, and I think it would be very helpful for the Dynamics 365 professionals, as authentication is the basic and most important piece of information needed while configuring PowerApps Portals for the customers.

What I like about the books in general is it gives us all the required information at the same place, instead of being scattered all around out there in the web, and also that information coming from the expert(s) who have been working on it (because of which you’d be buying the book in the first place) adds to its credibility. The book not only covers all the required details (how and why) for setting up the authentication but also presents it simply and concisely. The chapters start with how to register the portals with the external authentication provider, the authentication mechanism available, settings required in portals, etc. There is a specific pattern or consistency about the way chapters are written in the book, which will make it very easy to be referenced when required. Being around 150 pages, the book was also a quick read.

Grab your copy at the link below !

https://www.amazon.in/PowerApps-Portal-Authentication-Debajit-Dutta-ebook/dp/B085X2HL4W