Hi friends!
I have a weird one where records created by an integration user are not triggering the creation of "Lookup Rollup Summary Schedule Items" records for the scheduled rollup jobs to run.
I have tried adding additional permissions to the user including additional access to the parent/child records and various DLRS objects. The user has the Modify All Data permission as well as access to all the dlrs apex classes. I can't schedule the job with the integration user either to test that.
I'm totally drawing a blank on what else to check, so if anyone has any thoughts, I would be very grateful!
Hi Zarina - two things are likely tangled together here: what the Integration User license can do, and a field-access gap on the schedule-item object.
On the license: the Salesforce Integration User (the API-only license) is deliberately restricted - it's built for system-to-system calls, not for running platform automation. Not being able to schedule the DLRS job as that user is expected behavior, not a permission you're missing - so I'd stop trying to schedule or run the job AS the integration user.
On the schedule items not being created: DLRS creates those Schedule Items from the child Apex trigger, which runs as whoever did the DML - here, the integration user. If it works for other users but not this one, it's almost certainly a field-level access gap, because Modify All Data grants record-level CRUD but does NOT grant field-level security - FLS is separate. So the trigger can be blocked from writing fields on the schedule-item object even with Modify All Data set.
What I'd do:
- Assign the DLRS package's own permission set to the integration user (it grants the object, field, and Apex class access together as a set), and explicitly grant FLS on the Schedule Items object fields via a permission set - don't rely on Modify All Data for that.
- Turn on a debug log for the integration user, create a record through the integration path, and check whether the DLRS trigger runs and whether the schedule-item insert throws. DLRS tends to swallow these errors, so the log is where you'll actually see the FLS/CRUD failure.
Design-wise, separate the two concerns:
- The trigger that CREATES schedule items can run as any user (fix the FLS above so the integration user's DML creates them).
- The scheduled JOB that PROCESSES them should be scheduled/owned by a regular admin or automation user - not the integration user, which can't hold that schedule.
And if these rollups need to reflect integration-user data immediately and the volume is manageable, another option is switching those specific rollups to Realtime mode - it calculates in the same transaction and skips the schedule-item plus scheduled-job path entirely, sidestepping the license limitation altogether.
Hope that unblocks it!
