Understanding Business Rules in MS Dynamics CRM

 

Scope:

The scope of business rule can be either ‘Entity’ or ’All Forms’. When we select the scope as ‘Entity’, it executes at server side. The business rule fires whenever that entity is created or saved either from the form inside CRM or from any web application.

Selecting Entity as Scope

The scope ‘All Forms’ is selected when the business rule is to be executed at client side. In that case, the business rule is fired when the form is loaded or updated only at the client CRM form. Read more here.

Selecting All Forms as Scope 

Limitations:

• One of the limitations of business rules is that they are not executed during bulk edits and imports.
• We can’t debug and trace business rules like we do the JavaScript.
• The actions that can be performed using business rules are limited compared to the requirements a developer has to meet, like setting a field value by appending two other field values and hence forces them to depend on JavaScript.
• Also business rules are launched in the order they are activated. So one has to know all the business rules and the order in which they are to be executed in an entity.
• The number of If…Else statements in a business rule is limited to 10.
• The execution of a business rule is always enforced. There is no control over their execution. When a JavaScript and business rule acts on the same field of a form, the precedence is for System JavaScript followed by Custom JavaScript and then business rules.
• A JavaScript cannot be called from a business rule.
• A business rule can be acted only on the fields of local entities and not on the fields like look up of related entities or parent entities. Also business rules can’t interact with tabs and sections.

Setting Business Rules in MS Dynamics CRM:

To view the Business Rules, you can login to your MS Dynamics CRM page and select the appropriate option (for example Sales> Contact). Then select the entity and click New> Form> and click on Business Rules. You can view all the previously created business rules. Example given below.

For creating a new business rule, you can click on the ‘New Business Rule’ option on the bottom right corner of the screen. As illustrated in the first two screenshots, you can follow the instructions given and set the business rules as needed for fulfilling your business purposes.

Azure DevOps for Dynamics 365 using Power DevOps Tools

 

Azure DevOps for Dynamics 365:

Introduction

In this Chronicle, we will explore the use of Azure DevOps for Dynamics 365 (and applying more generally to the Power Platform).

We will see how it can be used to set up CI/CD Pipelines in your environments! Please check our CI/CD category with a lot of articles that could complete this one. 

This could be a great tool to:

• Automate your deployments across environments
• Save time
• Reduce manual errors
• Reduce manual manipulations

To understand this, I made a tutorial that we will follow together. We will then see the results of it, and how we could go further.

 

Tutorial - Presentation

We use 2 environments for the tutorial:

• A Dev environment (called CRM513268 in the printscreens)
• A Target environment (that could be your Production environment, or an environment used for testing the developments before pushing them to Production)

We make customizations in Dev environment in a Solution called "EasySolution".

In a Build pipeline, we export this Solution and publish it as Artifact.

If it runs successfully, a Release Pipeline is triggered. It will use the exported Solution and import it to Target environment. Before the import, an approbation from the System Administrator is requested.

 

Tutorial - Tool

In Azure DevOps we will use the tool "Power DevOps Tools" to automate the Builds and Deployments of our Dynamics 365 Solution.

This tool contains many Tasks such as: 

• Update Configuration Record
• Backup Online Instance
• Check Solution (with PowerApps Checker API)
• Export Solution
• Import Solution
• Set Version
• Publish Customizations
• Create Patch
• Import Config Migration data

You can check the exhaustive list (and other information about the tool) in this link:

https://marketplace.visualstudio.com/items?itemName=WaelHamze.xrm-ci-framework-build-tasks

 

Tutorial - Build

Let's start with the creation of the Build Pipeline.

Go to the Azure DevOps Portal: https://dev.azure.com/

Create a project and open it:

Mine is called "CRM CI CD".

You land on the "Summary" page of the project. We will focus on the "Pipeline" tab:

 

Click on "Pipelines" tab and click "New Pipeline".

 

By default, the pipeline is edited with YAML code. You can click "Use the classic editor" link. This will open a graphical interface to edit the pipeline.

Then, you will be asked to select a Source:

 

You can select a repository you already have, or create a new one.

We will actually not use any repository in this tutorial. But this step is mandatory.

Next, you can choose to start your pipeline with a template, or create an "Empty Job":

 

Here we will start with an empty job.

We will use the Agent job already created. In it, add a new task and look for "Power DevOps Tools":

 

If you haven't installed it your environment before, you will find it in tab "Marketplace" with button "Get it free". So you can click it, it will redirect you to the Visual Studio marketplace. There you can click "Get if free" again and it will be added to your Azure DevOps.

And now... we are ready to get into the core of the subject and add content in our pipeline !

Add the Task "Power DevOps Tool Installer":

 

This step installs the "Power DevOps Tool" tool in the Agent Job.

Then, add the following Tasks:

• "Ping Environment"
• "Publish Customizations"
• "Set Version"
• "Export Solution"
• "Publish Artifact"

And you get this pipeline:

 

Let's review each Task one by one.

• "Ping Environment":

 

This Task just allows to check that the connection to the environment can be made successfully. It is mainly useful while building/debugging the Pipeline.

You can change the Display name if you want.

You need to enter the Connection String to connect to your environment. There are different possible ways to connect, for instance with a user account or with a Service Principal.

The possible formats of the Connection String can be found there: https://docs.microsoft.com/en-us/powerapps/developer/data-platform/xrm-tooling/use-connection-strings-xrm-tooling-connect#connection-string-parameters

To store the Connection String, I created a variable called "ConnectionStringSourceEnv":

 

To reference a variable in the pipeline, the syntax is $(name_of_the_variable)

There are other parameters, common to Azure DevOps Tasks: the "Control Option" and "Output Variables". "Control Options" allow to:

-Enable/Disable a Task

-Choose to stop the execution of the Pipeline or not if the Task fails

-Set a timeout

-Choose in which case to run this Task:

 

 

• "Publish Customizations":

This Task publishes the customizations in your environment. This can be useful if you want to be sure to export all customizations.

The parameters are the same as for the "Ping Environment" Task. You just have one additional parameter "Connection Timeout" that allows to set a timeout for the Connection to the environment.

 

• "Set Version":

 

For Target, select "Solution in CRM". This option allows to work directly on the solution in the CRM.

In Connection String, enter the variable already created for previous steps. 

In Solution Name, enter the exact name of the Solution you are working on. Here, ours is called "EasySolution".

In Version Number, we choose here to reference the Build Number of the pipeline. This is done with that syntax: $(Build.BuildNumber). And for the Build Number of the pipeline, we set it to : 1.0.0$(Rev:.r) in tab Option, field "Build number format":

This syntax allows to set a build number of kind 1.0.0.1, with the last digit increasing at each build run. Of course, set the version number as you prefer, depending also on the way you want to use your pipelines.

 

• "Export Solution":

Again, for this step enter the variable of the Connection String.

Put again the name of your Solution. 

You have checkboxes to choose if you want to export the solution as Managed, Unmanaged, or both.

In the Output path, you can enter $(Build.ArtifactStagingDirectory). That's the file where the exported solutions will be placed.

 

• "Publish Artifact"

 

Finally, in this step we publish the artifacts that were created previously.

In "Path to publish", add the output path of the previous step. Here, it is: $(Build.ArtifactStagingDirectory)

And add the name of your Solution. Here it is "EasySolution".

 

Your build pipeline is now ready!

 

Tutorial - Release

Now we would like to add a Task to import our exported Solution in the Target environment.

We could add the "Import" Task in our Build pipeline. But we will rather put it in a Release Pipeline, which will allow us to use some nice features such as Pre and Post-deployment conditions.

 

So, go to "Releases" tab and create a New Release Pipeline. 

 

There are several available templates, don't hesitate to browse them. In our case we start from an empty job.

Add an artifact. For the Source, choose your Build pipeline. For Default version, we take the latest (we could also for instance select a specific version):

 

Now, we add the two Tasks in the Release pipeline as follow:

 

As said before, the first step installs the "Power DevOps Tool" tool in the Agent Job.

Now, for the "Import Solution" step:

Enter the Connection String of your Target Environment. As for the Build pipeline, I created a variable to store it. And I reference the variable in this step.

In parameter "Solution File", you can browse in the Artifacts to get the exported solutions of the Build pipeline.

And then you have some checkboxes. We choose here to Publish Workflows after importing the solution, to use Asynchronous mode.

You could also convert an unmanaged solution into a managed one; you could override a solution in the target environment event if it has the same version; etc.

 

We are almost done. Now, come back to the Pipeline view and select the "continuous deployment trigger" icon:

 

And click Enabled. This will automatically trigger the Release pipeline when a new Build is available !

Finally, we add a Pre-deployment condition:

 

We enable "Pre-deployment approvals", and in "Approvers" field, I add the System Administrator.

So, when the Release gets to this point, a mail will be sent to the System Administrator, and he will be able to validate or reject the request.

If he accepts it, the solution will be imported in the target environment. Otherwise it won't be imported. It is great way to keep control on the deployments !

 

Test !

Now, let's test our Pipelines !

We start with our solution "EasySolution" being in version 1.0.0.1 in our Dev and in Target environment:

 

 

I have made a little customization in Dev environment in the Solution "Easy Solution". And I want to push this customization to Target environment. So I will use our DevOps Pipelines !

On purpose, I do not change the version of "EasySolution" in Dev environment, as it will be done by the Build Pipeline.

In Azure DevOps, I manually trigger the Build Pipeline.

After a bit more than 2 minutes, we see that the run was successful:

 

And we can indeed see that the "EasySolution" has been set to version 1.0.0.2 in Dev environment:

 

In the Artifacts of this Build, we can see that our Managed and Unmanaged solutions have been exported:

 

In the Release Pipeline, we see that a new Release has been automatically triggered for this Build:

The Release is pending Approval from the System Administrator before going further.

And the System administrator received a mail:

As System Administrator, I now approve the request.

And after a few minutes, the Release pipeline has successfully run:

 

And now, in Target environment the "EasySolution" is set to version 1.0.0.2:

 

And here we are ! Now customizations I make in Dev environment can be automatically pushed to Target environment, with a validation process !!!

It just takes to click on a Button to trigger the Build Pipeline!

 

Go further

There are several ways to go further in your Azure DevOps Pipelines for Dynamics 365. Here are a few ideas:

• You could add testing Tasks (with "Visual studio Test" Task) in your Pipelines. If a Test fails, the Pipeline would stop and a notification would be sent. You could Test the CRM using the APIs, or directly test the User Interface using EasyRepro or Selenium (you can see this chronicle to learn more about UI testing on the CRM: Dynamics 365 EasyRepro - Automated test framework)
• Your Build pipeline could be triggered by a push in a Git repository
• You could add more pre-deployment/post-deployment conditions
• You could adapt this tutorial for managing 3 environments instead of 2

 

Conclusion

To conclude, Azure DevOps is really a powerful product to manage the CI/CD on your Dynamics 365 environments. And more generally, on the Power Platform.

It is very intuitive and quick to put in place.

This may allow you to manage more easily your tests and deployments across environments !!

Set CRM Email Recipients in Power-Automate using OData Binding

 

DESCRIPTION

The provision for creating and sending Dynamics 365 CE (CRM) Emails from a Power-Automate (MS Flow) has always been appreciated due to its simplicity. But setting the Email Sender (From) and Recipients (To/CC/BCC) dynamically is always tricky. In this blog, we will learn how a CE Developer can set these Parties for an Email dynamically in a Power-Automate using OData Binding.

Please note that we have 11 different types of Activity Parties in Dynamics 365 for Customer Engagement and Microsoft crm development. An Activity Party Type is stored as an integer value in the attribute - ActivityParty.ParticipationTypeMask. For an Email Activity, we have the following Activity Party Types:

Activity Party Type	Activity attribute	Integer Value	Description
Sender	Email.From	1	Specifies the sender.
ToRecipient	Email.To	2	Specifies the recipient in the To field.
CCRecipient	Email.Cc	3	Specifies the recipient in the Cc field.
BccRecipient	Email.Bcc	4	Specifies the recipient in the Bcc field.

Are you planning to create and send Dynamics 365 CE emails using power-automate?

Then the ultimate solution is to pass on your query to us. We are at your service and will provide the best services.

Contact Us

For this blog, we will consider a simple requirement to develop a Power Automate – Once an account name is updated, an email must be triggered by the user who has modified the account to the Primary Contact, keeping the Account Owner (user) in CC.

STEPS

• We begin with creating a new Power-Automate (Flow) - Send Email on Account name update. It triggers on Update of an Account Name.

  

• We next initialize an Array Variable – Email_Recipients. We bind the “From” to the user who has updated the account name, “To” to the account primary contact and we “CC” the account owner. Please note that the property “participationtypemask” is 1 for “From”, 2 for “To” and 3 for “CC”.

  

  You can copy the value from below.

  [

  {

  "participationtypemask": 1,

  "partyid@odata.bind": "systemusers(@{triggerOutputs()?['body/_modifiedby_value']})"

  },

  {

  "participationtypemask": 2,

  "partyid@odata.bind": "contacts(@{triggerOutputs()?['body/_primarycontactid_value']})"

  },

  {

  "participationtypemask": 3,

  "partyid@odata.bind": "systemusers(@{triggerOutputs()?['body/_ownerid_value']})"

  }

  ]

• Then, we add another variable – Email_Body and initialize it with the string - “Hello, Account name is updated to <new account name>”.

  

• Next, we create a new CDS record – Email Messages. Make sure to switch to input entire array for Activity Party Attributes.

  

• We assign our array variable – Email_Recipients to Activity Parties.

  

• We assign the string variable Email_Body to the Description attribute. We set the Email Subject – “Account Name Update.”

  

• Finally, we add a new CDS action – Perform Bound Action to send the Email message. Save these changes.

  

UNIT-TESTING

• We update an account name and check if our Power-Automate Send Email on Account name update has been executed successfully.

  
  

• We verify that the CE Email record is created and sent successfully as expected.

  

CONCLUSION

Hence, we comprehensively learned in this blog how a CE Developer can set the Activity Parties for an Email (From/To/CC/BCC) dynamically in a Power-Automate using OData Binding.

That’s all from this blog, see you in my next one.