Book Image

Microsoft Dynamics 365 Extensions Cookbook

Book Image

Microsoft Dynamics 365 Extensions Cookbook

Overview of this book

Microsoft Dynamics 365 is a powerful tool. It has many unique features that empower organisations to bridge common business challenges and technology pitfalls that would usually hinder the adoption of a CRM solution. This book sets out to enable you to harness the power of Dynamics 365 and cater to your unique circumstances. We start this book with a no-code configuration chapter and explain the schema, fields, and forms modeling techniques. We then move on to server-side and client-side custom code extensions. Next, you will see how best to integrate Dynamics 365 in a DevOps pipeline to package and deploy your extensions to the various SDLC environments. This book also covers modern libraries and integration patterns that can be used with Dynamics 365 (Angular, 3 tiers, and many others). Finally, we end by highlighting some of the powerful extensions available. Throughout we explain a range of design patterns and techniques that can be used to enhance your code quality; the aim is that you will learn to write enterprise-scale quality code.
Table of Contents (19 chapters)
Title Page
Credits
Foreword
About the Author
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface

Using a Business Rule to show and hide attributes


Business Rules are a Power User's dream come true. They minimize the amount of custom JavaScript required on forms and they can replace some simple calculation plugins when the rule is scoped at the entity level.

In this example, we will create a simple Business Rule to show and hide the Student Id attribute based on the contact types defined in the first recipe of this chapter.

Getting ready

Similar to the previous recipes, a System Customizer or higher security role is required to perform the configuration as well as a solution to contain the changes.

How to do it

  1. Navigate to Settings | Solutions | Packt.
  2. Navigate to Entities | Contact | Forms and open the previously created Contact form.
  3. Double-click on Contact Type and uncheck the Visible by default checkbox.
  4. Click on OK, then click on Save and Close.
  5. Navigate to Entities | Contact | Business Rules and click on New.
  6. Under BUSINESS RULE: Contact, enter the title, Show/Hide Student Id.
  7. Click on the first available CONDITION and enter the following details in the right pane:
    • Display Name: Check Contact Type Student
    • Source: Entity
    • Field: Contact Type
    • Operator: Equals
    • Type: Value
    • Value: Student
  8. Click on the Apply button.
  9. Back in the main editor, click on Add | Add Set Visibly and select the + sign adjacent to the tick sign: 

Enter the following details, followed by a click on Apply:

    • Display Name: Show Student Id
    • Field: Student Id
    • Status: Show field
  1. Back in the main editor again, click on Add | Add Condition and select the + sign adjacent to the X sign:

Enter the following details:

    • Display Name: Check Contact Type Other
    • Source: Entity
    • Field: Contact Type
    • Operator: Equals
    • Type: Value
    • Value: Other
  1. Click on Apply.

 

 

  1. Click on Add action | Add Set Visibility and select the + sign adjacent to the tick sign for the new condition:

Enter the following in the right-hand pane:

    • Display Name: Hide Student Id
    • Field: Student Id
    • Status: Hide field

 

 

  1. Click on Apply in the right navigation pane, followed by Save in the main editor in the top left:
  1. Once saved, click on Activate on the main editor followed by Activate in the Process Activate Confirmation prompt:
  1. You can optionally click on the VALIDATE button to ensure that your business rules do not have any issues.

How it works

We started by marking the field as hidden by default in step 3. As a best practice, it always makes for a better user experience when hidden fields are revealed, as opposed to hiding visible fields on loading a record. In step 7 and step 8, we created the condition and rule to show the field; in step 9 and step 10, we created the converse condition and rule to hide the field. Always think about the reverse scenario when implementing business rules, otherwise, you will be faced with an irreversible action.

Given that the scope of the business rule was set to the default All Forms (top-right corner when editing the business rule), all forms will now respect that rule. If the scope was set to Entity, the rule would also trigger on the server side, which could be useful if implementing calculation rules that need to be respected when manipulating the data outside of a form (for example editable grids, bulk import, or through the Web API or SDK):

Behind the scenes, JavaScript functionality is created to address the rules' requirements. This is also respected in all form factors following the configure once, deploy everywhere design pattern.

Business Rules also have limitations, as follows:

  • There is a limit of 10 If Else conditions per business rule
  • Business Rules cannot control sections and tabs
  • If not set to a scope of Entity, a Business Rule will only run on load and on changes to the field, not on save.
  • Conditions cannot be a mixture of AND and OR; it's a set of one or the other

For additional limitations, visit https://technet.microsoft.com/en-us/library/dn531086.

There's more...

Business Rules provide a wide range of actions that can be performed. Among them are the following:

  • Show error message
  • Set field value (using another field's value, a static value, a formula, or simply clear it; it's good for simple plugin replacements)
  • Set visibility
  • Set default value
  • Lock or unlock a field

The TechNet article (https://www.microsoft.com/en-us/Dynamics/crm-customer-center/create-business-rules-and-recommendations-to-apply-logic-in-a-form.aspx) covers more details about Business Rule.