A client recently asked if we could disallow all users the ability to deactivate records. Why? Well, since there is no cascading deactivation for related detailed records, only parent records were being deactivated, yet the manager’s reports still contained information on the related detailed records. This led to reports with inflated forecast numbers and confusion, since users insisted that they’d removed the records in question and couldn’t understand why they were being included.
Reviewing The Parent Record Classification In Dynamics CRM
The client’s system allows the end-user to open the parent record, and then view and adjust the related detailed record via a Silverlight grid. To the end-users, deactivating the record at this secondary level would seemingly remove this record from being included in the aggregate sum of all units in the details reports. Unfortunately, this was not the right assumption, and this action caused the values to be included in the monthly records totals. This caused major issues in the finance group, which uses reports that look at the status of the detail records to determine inclusion in the sum.
Using the Ribbon Workbench to Customize the Activate and Deactivate Buttons
I did explain that if a button is hidden, then it’s hidden for all users, including the system administrators. After some investigation, I found a post (http://www.crmsoftwareblog.com/2012/05/managing-access-to-activatedeactivate-ribbon-buttons-in-microsoft-crm-2011/) introducing the Ribbon Workbench. This is different from the Ribbon Editor tool that I had been using in that it’s uploaded as a solution in CRM, becomes a workbench from within the customization entity, and allows customizing of button behavior.
In this case I wanted to hide the Activate and Deactivate buttons from the end-users, yet maintain the buttons for the system administrators. In order to accomplish this, I customized the buttons to only display if a user’s role had global delete privileges to the entity.
The following are the steps I followed once I installed and got familiar with the Ribbon Workbench:
1. Created a solution for the entity being updated.
2. Launched the Ribbon Workbench from Settings > Customizations ribbon.
3. Selected the solution that was created for the entity.
4. Right clicked on the Deactivate button.
5. Selected Customise Command.
6. Selected the entity that I wanted to edit the Deactivate button on. This is only required if the solution contains more than one entity.
7. From the Solution Elements section (bottom middle section), expanded the Commands option.
8. Right clicked on Mscrm.HomepageGrid.Deactivate.
9. Selected Edit Display Rules.
10. Selected the +Add New button.
11. Added the following Rule: Custom.<entity name goes here>.UserHasDeletePriv.DisplayRule
12. Select the Add Step button.
13. Select Entity Privilege Rule.
14. Set the following properties:
a. Entity Name:<the name of the entity you are working in>
b. PrivilegeDepth= Global
c. PrivilegeType= Delete
Note: Once the rule is created, it’s available for other areas of the form for the entity being updated.
15. Selected the Form option (top right corner) to add the same rule to the form when a record is opened. This was done by right clicking on the Deactivate button at this level and selecting Mscrm.Form.Deactivate command.
16. Added the rule that was created on the Homepage by selecting the rule and pressing Add.
17. Saved the record.
18. Published the Solution.
Although this solved the issue of conditionally displaying the Deactivate button from non-system administrators, the end-user still wanted the ability to remove unwanted records from their active view. In order to provide them this capability, I performed the following:
1. Created a new two-option check box field on the entity form called Deactivate. The field is hidden from view so that the users do not get confused as to its purpose.
2. Created a workflow to set the new hidden Deactivate checkbox field to Yes when the yearly total of the detail record updated to equal 0 for the year.
3. Updated the associated view for the entity to only display those records where Status = Active and Deactivate = No. This ensured that even though the record is still considered active, it’s removed from the view.
4. Sent communication to the end-users informing them that if they did not want the record to be included in the aggregate of the total sums, they needed to zero out the monthly numbers. By doing this, they would trigger the workflow to launch and would create the illusion of the record being deactivated. It also forced the end-user to clean up the record prior to removing it from their view so that the values won’t be included in the totals.