Classify parent based on number of child records in a master detail relationship

Question

I need to count the number of child records that a parent has in a master-detail relationship and based on the count, update a field on the parent. This field cannot be a formula field as it needs to be editable from the UI. I can count the number of child records using Roll-up summary field. But how do I update the other field? It cannot be done via a field update as roll up summaries are evaluated after field update. Is it possible to achieve this without code?

Answer 1

I tested this in a dev org and this should work properly with a normal roll-up summary field and a field update.

This is supported by the order of execution - as the action of creating the child record triggers the save behavior on the parent record when the roll-up is recalculated on the parent.

Item 16 on order of execution states:

If the record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the parent record. Parent record goes through save procedure.

So when you create a child record, the save on the child record triggers the roll-up summary field on the parent to recalculate, and the parent goes through the save behavior - which includes evaluation of workflow rules.

I tested a simple scenario in a dev org.

Create a roll-up summary field 'opp_count__c' on account that counts all opps.

Create a workflow rule on account that fires when 'opp count' = 2.

Add a field update that updates a text field, with the value of TEXT(opp_Count__c).

Create one opp. Nothing happens.

Create a second opp. The text field is updated.

Unless I am not understanding the question, this should be the standard behavior of roll-up summary fields - you can trigger workflows on the parent record based on a roll-up summary field value.

Reading again, it seems like you may want to set the value of a field based on the value of a rollup summary field, but then want to user to be able to edit it. That just requires you to set your workflow criteria appropriately, so it will fire when it should and then will not overwrite user changes. How to do so will depend on your use case but should be feasible. Please elaborate more and I can get into more details.

Answer 2

If you look at Order of Execution, one of the last things to happen before a record is finally committed to the database is the calculation of roll-up summary fields. That happens after all workflow rules, processes, escalation rules and entitlement rules have been applied. The only things that follow are cascading roll-up calculations, the actual commit to the database and post-commit operations like sending emails resulting from workflow. What that says is that there's no non-coded operations available to you that can translate your roll-up summary field data to populate another field as part of the same transaction.

In my view, it would seem to me that you'd have several options available to you. One solution would be to make this an @future call from a trigger where the record Id is passed into a queueable class every time the record is updated. In the queueable the parent is queried and the value of the roll-up field is copied into the duplicate count field that's editable. That would seem to me to be the simplest way.

Am alternative would be to use a trigger to perform all of the rollup calculations for the M-D relationship and have the trigger also copy the results value into the 2nd field for you. To me, the latter solution would seem to be far more resource intensive than the former solution. Another solution would be to have a scheduled batch class that runs daily to update the values for you on all records that have been updated since the previous batch class was run.

Which solution to use would be entirely a matter of deciding how critical it is that your records be maintained in real-time or close to real-time. The more flexible you are on that requirement, the more options you'll have.

Answer 3

You basically will need three fields

• RollupFromDetails__c
• IsRollupOverridden__c (type = checkbox)
• Rollup__c

Use DLRS to populate RollupFromDetails__c from the children (this is done with triggers but is a point and click solution)

Use a Workflow or Process Flow to populate via Field Update Rollup__c from RollupFromDetails__c unless IsRollupOverridden__c is true.

Thus, the rollup from children will auto-copy to the user-editable field as log as the user hasn't indicated they want to override the automatic calculation.

To restore the default value, simply uncheck IsRollupOverridden and the workflow/process will re-execute