The Timestamp frequency defines when the Booking Timestamp record should be created from the Bookable Resource booking record.
Per Booking Status Change
Per Field Service Status Change
By default, it is Per Field Service Status Change, in this case, the Booking Timestamp will be created on the change of Field Service Status.
Let us update a Bookable Resource Booking record’s status from In Progress to Arrived.
Here we will not see any Booking Timestamp record created as the Field Service Status remains the same – “In Progress”
On changing it to On Break, we can see a new booking timestamp record created as that changes the Field Service Status.
The booking timestamp record :-
In the case of Timestamp Frequency as “Per Booking Status Change”, the booking timestamp record will be created on the change of the booking status in the Bookable Resource Booking record.
Also in the case of “Pre Booking Status Change”, the booking timestamp record created will have the Booking Status captured which is blank in the case of “Per Field Service Status Change” as shown below
“To start using cloud flows, update to the latest package in the admin center.”
However, we could not find any portal package to apply the update.
We raised a Microsoft Support Ticket for it, and the team confirmed that there was a missing CDSBasePortal package, which they installed from the background, which solved the issue for us.
Recently we got the below error “Forbidden” for one of our flows that was using the Dataverse connection.
After some analysis, we found the root cause of the error.
The Dataverse connection reference was created using the Service Principal but it was not added as an Application User (with appropriate security role) in that environment.
Adding the corresponding Application User used for the Dataverse connection fixed the issue for us.
The content describes invoking a Webhook from a custom Azure-Aware Plugin, registered through a plugin registration tool. It includes code to invoke the Webhook using the IServiceEndPointNotificationService interface and a sample code snippet. The process involves updating a case record and provides guidance on the execution context and handling exceptions.
Below is our cloud flow that we have registered as a webhook through the plugin registration tool.
Below is our Webhook registered, note down the ServiceEndpointId.
Below is our code to invoke the Webhook, it uses the same interface, and we IServiceEndPointNotificationService need to provide ServiceEndpointId to it.
We have this registered in the Update message of the Incident.
Let us update a case record and see it in action.
Sample Code –
public class CallWebhookPlugin : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
IPluginExecutionContext context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
IServiceEndpointNotificationService webHookService =
(IServiceEndpointNotificationService)serviceProvider.GetService(typeof(IServiceEndpointNotificationService));
try
{
tracingService.Trace("Posting the execution context to the Webhook.");
// pass the GUID (ServiceEndpointId) of the Webhook
webHookService.Execute(new EntityReference("serviceendpoint",
new Guid("7b88a3c7-d2b5-ee11-a569-0022481c0ba7"))
, context);
tracingService.Trace("Passed Successfully.");
}
catch (Exception e)
{
tracingService.Trace("Exception: {0}", e.ToString());
throw;
}
}