Total child count is incorrect.

[nsinghCloudera]

Rollup does not calculate counts correctly; I'm observing scenarios where the total child count is always one less than the actual count. When I add the first child, its count is always blank, and upon adding the second child, it is set to 1. I'm unsure whether this is a rollup issue or if there's something I'm missing in the rollup setup.

[jamessimone]

@nsinghCloudera I'm going to need quite a bit more in the way of information if I'm going to assist. To start with, I'd recommend turning logging on in the Rollup Control org default record, and observing the logs for the first child. Please feel free to also take a screenshot of your config, as that might shed some additional light. If it doesn't, though, I'll need log files to assist further.

[nsinghCloudera]

@jamessimone After analysing the log, one thing I'm wondering is if there is a way to specify the execution order of these roll-ups through metadata. I have eight different roll-ups, and at a single time, at least 2 or 3 meet the criteria. I'm guessing this might be the issue as well. I'm not able to find any field where I can specify the execution order of these roll-ups.

[jamessimone]

@nsinghCloudera I'm not sure I understand your last comment. Are you saying that your rollups are dependent on being processed in a particular order? That would make it sound like you're filtering on parent level fields that are also being rolled up, is that correct?

[nsinghCloudera]

@jamessimone No, the rollups are not dependent on being processed in a particular order.

I have a custom object called Escalation, which is a child of Case. We can have different types of Escalation, such as Customer, Manager, or Engineering types. For each of these types, we count on Cases. Additionally, we have Total Escalation, which sums up all types, and Open Escalation, which counts all escalations that are not closed. If I create a Customer-type escalation, then the rollups for Customer, Open Escalation, and Total Escalation should also be executed. Based on the logs I'm seeing, they are getting executed in random orders. Sometimes, Open Escalation is processed first, followed by Total Escalation, and then Customer. Could this be the issue?

Here is my config screenshot:

[jamessimone]

@nsinghCloudera I'm a little confused.

No, the rollups are not dependent on being processed in a particular order.

But then you say:

Based on the logs I'm seeing, they are getting executed in random orders. Sometimes, Open Escalation is processed first, followed by Total Escalation, and then Customer. Could this be the issue?

To me, that sounds like you're asking about an order of operations issue. I am happy to help - please just let me know what I can do to assist!

[nsinghCloudera]

@jamessimone Sorry, for the confusion. I enabled logs and based on that let me explain what I'm seeing.

I have attached an excel sheet. This sheet contains two tabs; the first one contains logs after the first escalation record is created, and the second one contains logs after the second escalation record is created.

1. When I created the first Escalation, I saw three logs being generated. The first one sets values correctly, but the last one sets values to either 0 or null.
2. When the second escalation is created, the rollup values are updated by one, but not to the correct value.

Rollup Issue.xlsx

[jamessimone]

I'll try to take a look. I have limited time for open source work this week, otherwise I'll get to it next week.

[jamessimone]

@nsinghCloudera I'm not able to glean a lot out of what you've uploaded. Some of the other messages generated by the rollup logging framework, for example, would allow me to see if you have recursive updates occurring on insert based on the reported rollup context; in general, it's hard to say what's going on without a lot more information.

That being said, it's possible that I can diagnose the underlying issue without getting more in the way of information - COUNT-based rollups, by default, operate on a "diff based" calculation model. You can override this by toggling the "Is Full Record Set" checkbox on each metadata rollup metadata record. This has the effect of allowing the rollup framework to re-query for all possible children for a parent when performing calculations, and may fix the issue you're experiencing.

[jamessimone]

@nsinghCloudera I haven't heard back from you, but I hope the above information proved helpful. I'm going to close this one out for now.

[nsinghCloudera]

Hi @jamessimone Yes, this issue is fixed after setting "Is Full Record Set" to true. We are seeing one new exception which we are getting in scheduled job. I'll raise another one. Thanks for your help.