Business Process Flows (BPF) in Dynamics 365 offer a structured way to guide users through a defined process. However, there are scenarios where progression to the next stage must be validated against specific business rules. In this blog, we see how to implement custom validations on stage progression using JavaScript.
Let us take a simple scenario where a Lead can only progress to the next stage of a BPF if
Lead Quality = Hot and Lead Source = Web
If these conditions are not met, users will receive a notification, and the stage change will be prevented.
Below is the sample code
function OnLoad(executionContext)
{
var formContext = executionContext.getFormContext();
formContext.data.process.addOnPreStageChange(validateStageProgression);
}
function validateStageProgression(executionContext)
{
var bpfSampleStage = "6e2b5d9e-da30-4a47-8ca9-d75c24fd51f4";
var formContext = executionContext.getFormContext();
var rating = formContext.getControl('header_process_leadqualitycode').getAttribute().getValue();
var leadSource = formContext.getControl('header_process_leadsourcecode').getAttribute().getValue();
var stageObj = formContext.data.process.getActiveStage();
var stageId = stageObj.getId();
var requiredFieldErrorId = "contractValidationNotificationId";
formContext.ui.clearFormNotification(requiredFieldErrorId);
if(stageId)
{
if (stageId.toLowerCase() === bpfSampleStage)
{
if (executionContext.getEventArgs().getDirection() === "Next")
{
executionContext.getEventArgs().preventDefault();
if(rating == 1 && leadSource == 8) // rating = Hot and Source = Web
{
formContext.data.process.removeOnPreStageChange(validateStageProgression);
formContext.data.process.moveNext();
}
else
{
notificationMessage = "Cannot move to the next stage until conditions are met !";
formContext.ui.setFormNotification(notificationMessage, "ERROR", requiredFieldErrorId)
}
}
}
}
}
The addOnPreStageChange method registers the validation function on the form’s load event to monitor stage changes.
The preventDefault() method stops the stage transition if the conditions are not met, ensuring data integrity.
If the validation fails, an error notification is displayed using the setFormNotification() method, guiding users to correct the data.
Upon satisfying the conditions, moveNext() is invoked programmatically to move the process to the next stage.
As shown below, clicking on Next as rating and lead source values do not satisfy the condition, we can see the notification on the form and the user is not able to move to the next stage.
The new Smart Grid Preview feature allows us to find, filter, and sort data with natural language.
To enable it navigate to Environment >> Settings >> Features inside Power Platform Admin Center and turn on Natural Language Grid and View Search.
After enabling it we will see a search box on the grid page where we can type in questions about our data in plain English.
Let’s say we need to find “Contacts from the company Contoso”. Normally, this would mean defining the filters/query. But with the Smart Grid’s natural language search, we just type the request, and the system filters the view accordingly.
The result –
We can also use it to sort data.
Another example
The result –
Using natural language search has loads of benefits:
Ease of Use: Do complex searches without needing to be tech-savvy.
Speed: Find what you need quickly without navigating through multiple filters.
Accessibility: Makes data interaction easy for everyone, even if you’re not a tech pro.
As it’s still in preview, there are a few things the Smart Grid Preview doesn’t support yet:
Query Aggregation
Query Grouping
Adding Columns
Remember, it’s still a work in progress and not ready for full production use.
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.
Nishant Rana's Weblog 