Recently while trying to invoke the HTTP Request trigger, on passing the token we got the below error from the Postman
{
"error": {
"code": "MisMatchingOAuthClaims",
"message": "One or more claims either missing or does not match with the open authentication access control policy."
}
}
Turned out that we missed the trailing slash for the resource’s value while generating the token.
Below is our final Power Automate Cloud Flow which uses the HTTP request trigger followed by Response action.
The Allows Users = Specific users in my tenant option ensures that only authorized users in the tenant can trigger the flow while leveraging the security provided by Oauth authentication and Azure AD.
Let us first register an App in the Azure AD.
Go to API Permissions → Add a permission.
Select User permission.
Grant admin consent
Generate and copy the client secret.
Navigate to Enterprise Applications, search for the app, copy the Object ID of the App, and specify the same for the Allowed users property in the HTTP request trigger.
Now let us use the Postman to generate the token and call the flow. Note down the Application (client) ID and we can either use the v1 or v2 Oauth token endpoint.
Specify the following values if using the v2 endpoint to generate the token.
Recently we observed that our plugin registered on the Delete message of appointment on the PreValidation stage was not getting triggered when we were deleting or updating the occurrence of the Recurring Appointment.
For both of the below operations, our plugin was not getting triggered. The plugin had the logic to delete a few associated records to the appointment record.
Delete operation – This deletes all the existing appointment.
Recurrence Update –This deletes the existing appointment and creates new appointment records based on the new recurrence.
On trying out different things, we saw that the plugin was getting triggered if registered on the PreOperation.
For testing, we registered a sample plugin that throws the InvalidPluginExecutionException and saw it getting triggered in case of PreOpertaion as shown below.
The Case Handling Time widget (preview) can be added to the Case Form, giving a focused way to track case resolution efficiency. By using this feature, we can identify patterns, make informed decisions, and continuously refine processes.
To enable it to navigate to
Customer Service Admin Center >> Customer Support >> Case Settings >> Case handling time (preview)
Update Interval specifies how frequently the handling time widget is refreshed (it also updates the database). Can be between 10 to 60 minutes. The interesting point here is if 2 agents open the same case at the same time, the widget will display 20 minutes, after 10 minutes.
Next, open the form where we want to add the component, click on Get more components, and search for the Handling Time component to add it.
Configure the properties for the component –
Table – Time Trackers
View – All Time Trackers
Allow users to add time logs – True / False (enables agents to log time)
Show users only their contributed time – True / False (specifies whether an agent can only see their time or time entered by other agents also for that case)
Allow users to edit their automatic time tracked – True / False (specifies if an agent can edit automatic time tracked).
Save and publish the changes.
We can see the Handling Time widget at the bottom right corner in the minimized state on the form.
On maximizing it after some time, we can see the following details there.
Automatic Time Tracking, Manual Time Tracking, History section.
Checking My Time shows the Live time spent by that particular agent.
Clicking on the plus button allows us to add manual Time log records.
If there is a second user who opens the form, the automatic time tracking shows the values applied to that user.
We might get the below error while using LINQ to query Dataverse –
System.NotSupportedException: ‘The method ‘GroupJoin’ cannot follow the method ‘SelectMany’ or is not supported. Try writing the query in terms of supported methods or call the ‘AsEnumerable’ or ‘ToList’ method before calling unsupported methods.’
This error occurs because the GroupJoin method, which is essentially what happens during the into … syntax in LINQ, is not supported in the Dataverse/LINQ provider for Dynamics CRM. The issue is related to how the LINQ provider translates queries into FetchXML or SQL that the Dataverse understands. Specifically, nested joins or SelectMany (used by DefaultIfEmpty() in left joins) are not fully supported by the LINQ provider for Dataverse.
The GroupJoin and DefaultIfEmpty methods (used for left joins) result in queries that cannot be translated directly into FetchXML. The LINQ provider for Dataverse does not support all LINQ-to-Entities features, such as nested joins or advanced grouping logic. When you perform nested joins with DefaultIfEmpty() for left joins, the LINQ provider struggles to translate it into the underlying Dataverse query format, which is why the exception is thrown.
To fix it we can break the query into multiple steps as shown below.
However, here as we are fetching partial data into memory and combining it, it increases transfer and processing overhead and can take a long time to process based on the number of records.
The better alternative from a performance perspective would be to use FetchXML or QueryExpression here.
We might get the below error while using LINQ to query Dataverse – “System.NotSupportedException: ‘Invalid ‘where’ condition. An entity member is invoking an invalid property or method.’” Here we got the below error because we used the HasValue property.
Here the issue with HasValue arises because FetchXML doesn’t have a direct equivalent for nullable checks like HasValue in LINQ. In FetchXML, null checks are handled explicitly through conditions like neq (not equal) or eq (equal) with the null value. Therefore, instead of using HasValue, we need to manually check for null using != null or GetValueOrDefault().
We will also get the same error on below query.
Here we get this error because OriginatingLeadId is a LookUp referencing Lead table, and we are trying to access the Name property of it in the where clause, which cannot be directly translated into FetchXML. To fix it we can perform a join between the Contact and Lead table.
Let us see one more example.
The query, c.Attributes[“firstname”].ToString() is trying to access the firstname attribute and convert it to a string. However, the LINQ provider doesn’t know how to translate.ToString() into a valid FetchXML query.
To fix it we can use GetAttributeValue method.
Or doing the casting
However, we will get the same not supported error if we try to use Attributes Collection.
The error occurs because of the syntax c.Attributes[“firstname”] directly accesses the internal Attributes dictionary of the Entity object. The LINQ provider in Dataverse (Dynamics 365) cannot translate this access pattern into a FetchXML
Nishant Rana's Weblog 