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
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;
}
}
Let us fetch 5000 contact records using List Rows, and then update it using Apply To Each.
It took around – 37 minutes
Now let us enable concurrencycontrol for Apply To Each action, and let it run under 20 (default) degree of parallelism.
This time it took around 4 minutes.
Let us increase it to the maximum this time, i.e. 50.
This time it took around 2:45 minutes.
Thus Concurrency Control option can help in processing records faster by processing records in parallel instead of one by one by using parallel threads. However, if the ordering of the way records need to be processed is critical, then we need to be careful before using it and also at times it can cause the API’s request limit to be hit.
We might see some of the custom actions not appearing in the Actions list inside the Perform Action step of the workflow.
This is because the Custom Action would be using one of the following parameter types, which is not supported for Perform Action like
Picklist (Optionset)
Entity
Entity Collection
E.g. we have the following actions defined few are bound to the Contact table, some are Global, and have different types specified as either Input or output parameter.
Out of the above actions defined, we can see only the following actions listed inside the perform actions step of the workflow.
The action which has input as Entity Reference are the ones listed, as it is one of the supported types. For the unsupported types, if used as an output parameter, the actions are listed.
Microsoft has always recommended managed solution(s), apart from the some of benefits that managed solutions offer over unmanaged, Microsoft is also adding features to the managed solution, making it easy for teams to adopt and transition to Managed solutions, like focusing on making the solution import faster and adding ALM-specific features to it.
Let us take a simple example to see it working –
Suppose we have 2 environments, a Test and a Managed environment.
The test environment has 2 unmanaged solutions from different publisher that is already deployed to the target environment as unmanaged.
Source –
Target –
Ideally, we should be creating 2 copies of production environments, one for creating the new unmanaged solution (s) containing the components to be converted to managed and the other environment where the unmanaged solution (s) will be converted to managed and will be used for testing and validation.
Select source solutions and the target solution (combined) in our case, and click on Copy Components.
Here we have selected all the component types.
Back in our TestEnv, we can see the components of the solution added from Pub 1 and Pub 2 solutions to the combined solution.
Let us export the combined solution as managed.
The other way to create the combined solution would be to “Include all objects” for unmanaged components like custom tables. For managed components, like out-of-the-box tables lead, contact, case, etc, we’d only select the components customized.
Run the below command, to connect to the destination (managedenv) environment.
We can see the managed solution imported successfully to our target environment.
For quick reference –
Unmanaged
Managed
Unmanaged solutions are intended to be used in the development environment.
Managed solutions are intended to be distributed and installed.
Unmanaged solutions can be exported either as managed or unmanaged.
Managed solutions cannot be exported
Components can be directly edited within an unmanaged solution.
Components inside the managed solutions cannot be edited directly. Editing can only be done in the corresponding unmanaged solution or an additional unmanaged solution in dev and then exported and imported as managed in the target environment.
The unmanaged solution can be seen as the source code
A managed solution can be seen as a compiled code.
Deleting an unmanaged solution only deletes the solution container, all unmanaged customizations remain in effect and are applied to the default solution of the environment
Deleting a managed solution removes the customizations from the environment.
Benefits
Benefits
Unmanaged solutions allow for real-time customization directly within the environment.
The managed solution secures the solution components in the environment, by restricting the user from making changes or removing components from it.
Developers can make changes on the fly without the need for importing/exporting solutions
Ability to uninstall/roll back. In case of issues or undesired changes, managed solutions make it easier to roll back to a previous version. This can be crucial for maintaining system stability and ensuring minimal disruption to ongoing operations
The managed solution supports layering allowing multiple solutions to be installed simultaneously without conflicts.
Clearly defined component ownership in the case of multiple publishers/solutions.
Improved solution import performance with reduced performance impact on the environment.
We can see Active Contacts has a dependency on the custom column, and it is part of an unmanaged layer (default solution) in this case.
Click on Remove active customizations
This will delete the unmanaged customization done in the Active Contact view in the environment. (removes the custom column from the Active Contact view)
Trying again, this time we can delete the Managed solution.
Nishant Rana's Weblog 