Commons Project: DLRS

The general instructions are to work with Support through your case and let them know that they can collect the unmasked logs. Assuming they can catch it in the act, otherwise it might be hard for them to capture the logs. 

They will probably need approval, the internal contact for that is Cori O'Brien. She is a Salesforce employee and works with the community side of things, such as DLRS. She can approve the log capture and coordinate to get them reviewed. 

I hope that helps get the next steps moving for you. I'm around for any updates and questions.

@Sangeeta Belani

if you're not familiar, DLRS is a customizable rollup application. You go into the app and configure rollup definitions and in many cases the app generates triggers and test code that should be installed in your org to help make the rollups work. (there is a helpful UI for installing and removing these generated triggers) 

"dlrs_ContentDocumentLinkTrigger" is one of those auto-generated triggers. The error you're getting suggests you have a rollup definition that references ALC_Attachment_Count__c as a field. I assume you have a rollup from ContentDocumentLink up to Case and maybe ALC_Attachment_Count__c is the Result Field where the count of attachments should end up. 

To resolve the error you'll need to look through your DLRS configured rollups and find the one that references that field. Then you'll either need to repair the definition (why does it reference a field that doesn't exist) or you'll want to deactivate or possibly delete that rollup. Before deleting you'll want to evaluate if you need the trigger or if that should be removed first. 

Hope that helps you get on the right track.

Just giving an update here. I was able to experience the problem but digging into the details isn't easy. 

It looks like our recommended setup isn't getting a Refresh Token in the OAuth process. I'm trying different settings to see if I can correct it but the iteration cycle is very slow. 

I'm hoping I have an answer for you by the end of this week but it depends on how quickly I can figure out what needs to change.

The core issue is that you have Account records where the Lookup field holds the Id of a record that can't be resolved. 

Is it possible this is because of sharing/visibility restrictions that prevent you from seeing the record? (Maybe you have rollups in User mode vs. System mode too?) 

Anyway, assuming you have full access in the system and the lookup field points to a record id that doesn't exist in your system. The fix is to empy out the lookup field or to change it to another record. You can try and clear the value when editing but you may need to use something like Data Loader to set a blank value on the lookup field. 

If you already have an open support case I may suggest trying to see if they can explain why you're seeing that odd data condition. I'd hate to recommend mutating your data if there is a perfectly reasonable reason why it is behaving like this.

Reporting back on our call. 

It looks like you're getting the red errors when DLRS tries to see if it can access Salesforce's external APIs using the session id borrowed from Visualforce. This is usually caused when you enabled the setting so sessions are limited to the IP address where they originated. This is because the Visualforce session is tied to your browser's IP address but DLRS is trying to come from Salesforce's server IP and is being rejected. 

It doesn't mean that session setting is bad, only that it can cause some problems for DLRS' way of doing things. 

DLRS' new beta page uses different strategies for managing the rollup records and is generally able to avoid these problems. The current beta pages still rely on some of the older Visualforce pages, like Full Calculate, which once you've started the job they will try and return you to the old wizard and you're faced with the red error banner again. The job is started correctly but it then passes you to an error page, making it feel like it crashed. 

We worked through this by going to Setup > Apex Jobs which allowed us to check on the recalculation batch job and see that it was running and processing your records without reporting errors on the batch job. We also checked your Lookup Rollup Summary Logs object and saw that you were not generating new log records, which means the recalculation was working. 

When we looked into your individual rollup outcomes we found some data issues that made it look like DLRS wasn't behaving correctly. We were able to test this by modifying the data and recalculating again, DLRS did its job and you got the values you needed. 

Thanks for taking the time to go through this with me, glad we were able to find you answers.

@Joshua Danis

there shouldn't be any breaking changes from 2.19 to 2.25. Always give it a run in a sandbox first but there shouldn't be anything to worry about. 

You can review release changes here,

Let me know if you have any specific questions.

@Friedrich Stoltzfus

normally I'd send you to the docs but I see you've already checked the tab. 

There is an open issue for this that I think is related. DLRS checks to see if it is a storage issue then naively assumes everything else must be this error. 

I'd start by checking your storage in the sandbox, the code should be checking for storage issues but I think that check might be broken. You'd be at least the second person to experience this. 

If your storage is clean then please let me know and we can dig further. 

DLRS has two places that it keeps configurations, the Custom Metadata are the "modern" way but if this has been installed in your org for a while you might also have some of the Custom Object variety. I would check both for possible configuration locations. 

If it isn't present then it is more likely that DLRS is updating something else and triggering another automation, either on write to the Account object generally, or because of a specific field change. 

If you use the Apex Debug Logs you won't be able to see the DLRS code running but if the update is happening outside of DLRS then hopefully you can see that occur and find the source.