As a followup to this question, Contact last-modified date changed by read-only user - it appears that the source of the issue might be that a read-only user some how activated APEX batch jobs that appear to be part of the NPSP (non-profit starter pack); NPSP-info & NPSP-code.

Here's a screenshot of the Apex Jobs; note that under "Submitted by" that I've replaced the real "read-only" user's name with read-only, and my name with SysAdmin; everything else should be as it is seen in Salesforce:

Apex Jobs

SOURCE: [insert-instance-id].salesforce.com/apexpages/setup/listAsyncApexJobs.apexp

Apex Classes listed above appear to be:

  • BATCH_OppRollup
  • RecurringDonationsPkgVersionCheck
  • RecurringDonations_BATCH
  • SCHED_OppRollup

Of note is that on 2014-05-20 1000s of contacts were flagged with the read-only user's name under the last-modified-date field with a time-stamp of roughly 11:45ish of 2014-05-20. This time-frame paralleled a group training session, but it appears that the issue may go back to when the user first got read-only access. The events with the SysAdmin (me) match the time stamp (5/1/2014 8:15 AM) for the install of that package in installed packages reports.

What are these APEX jobs? How and where were they activated by the user? Is there a way to figure out what if anything they did? How do I kill them? Going forward, if they're not required, how do I hide and/or disable them from users?

  • 1
    +1 "How do I kill them?" I thought you meant the user for a second. The only thing I'd add to this is the only way to prevent managed code from executing is to make sure they don't have access to the classes or the pages that access those classes (see their profile's Visualforce Page settings and Apex Classes settings).
    – sfdcfox
    May 22, 2014 at 16:59

3 Answers 3


Looks like fun! The only way this can occur is if job was deleted, and then your read-only user hit Recurring Donations Settings page before you or somebody else did.

You can just delete the job as eyescream mentioned above, then navigate to the Recurring Donations settings page and it will reschedule as you, the jobs will then run as your user from that point on. I'd also lock-down your read-only user's profile to avoid this happening again.

Incidentally, the repos you want are here for the version you're running: https://github.com/SalesforceFoundation/Recurring_Donations

and here for the next release: https://github.com/SalesforceFoundation/Cumulus

  • Thank you, appears to be an answer/solution, it though doesn't really explain why the job is modified 1000s of records which didn't have any related opportunities, or why this appears to have only happened when the job was not scheduled; to see what I mean, please take a look at the pic of the Apex Job that ran on 2014-05-20 @ 11:42 AM in the question (link here too), which is when the 1000s of records had their last-mod-date changed. Seems something different happened, but unable to recreate it; meaning other than at that time no last-mod-dates changed.
    – blunders
    May 22, 2014 at 20:44
  • Tough to say, they update based on calculated forecast dates for the Recurring Donation (so, 12 months of forecast, monthly giving == 1 opportunity per month) I don't really see the 1000s of records there, can you show me what you're seeing modified that shouldn't be?
    – kmb
    May 22, 2014 at 22:38
  • There are no recurring donation in our SF build; believe it's likely that on the apex-jobs I linked to that the jobs related to the RecurringDonations were a result of that user with a read-only profile clicking that link on 2014-05-03 that started a daily-job on 2015-05-15, and is doing nothing since there are no Recurring Donations entered. Beyond that, appears that the 2014-05-20 @ 11:42AM Apex job was an OppRollup and a result of the same user clicking an OppRollup link 2014-05-20 @ 11:42 AM.
    – blunders
    May 22, 2014 at 23:28
  • As for numbers, I'll attempt to post numbers based on reports in 24-hours. Though the general gist is that minutes after the OppRollup Apex job on 2014-05-20 @ 11:42AM that massive amounts of our contacts had their last-mod-date updated and assigned to the user that happen to make all of this possible; I spoke with that user the day of the event in person and today by email, and they claimed to have zero idea what happened; really don't see this as there issue though, since I very clearly believed read-only was read-only, and that was my mistake, not their mistake.
    – blunders
    May 22, 2014 at 23:52

List of scheduled jobs can be found in Setup > Jobs > Scheduled Jobs. You'll also be able to delete / reschedule them from this page.

Code access to this (to filter by submitter's Profile for example) is possible through the CronTrigger and CronJobDetail tables (2nd one is a Spring'14 addition, here's the release note with more goodies).

SELECT CreatedBy.Name, CreatedBy.Profile.Name, CreatedDate,
    CronJobDetail.Name, CronJobDetail.JobType,
FROM CronTrigger
WHERE State != 'DELETED' AND CronJobDetail.JobType IN ('7','9')

Might be worthwhile to file a bug that they don't follow their own best practices and AppExchange submission rules - there should be a check in that code that throws errors similar to



You probably would be best consulting the NPSP documentation as to why they've executed. But we're developers, reverse engineering is in our blood :)

No idea if https://github.com/SalesforceFoundation/NPSP-UM is the correct repository, looks bit old. There are few classes that use Database.executeBatch or System.schedule. Play with the search? https://github.com/SalesforceFoundation/NPSP-UM/search?q=%22.execute%22&type=Code

I'm not familiar with NPSP but I'm willing to bet somebody accessed VF pages that have these guys as controllers:

  • householdsSettings.cls
  • RecurringDonationsSettings.cls

Pretty descriptive names ;)

Has this user configured something prior to the training session?

  • +1 Yes, the user appears to have created the job on 2014-05-03, 7-minutes after activating their SF-ID. It's a bit odd how the "total batches/batches processed" was ZERO before & after the training, which makes me think something also happened during the training. The last-mod-dates only appear to be on the 20th at a time when the batch is not scheduled to run, which is at at 6:11 AM. Note that the other days between the 15th & today all start at 6:11 AM, not another time, such as 11:42 AM as they did on the 20th, as you can see in the pic in the question.
    – blunders
    May 22, 2014 at 18:23
  • Just emailed the SF Foundation Director of Product Development who is both listed on the code in question, and to my knowledge is still the lead, to see if he has any suggestions; linked to this question, so it's possible he'll reply here, but if I do figure out more, I'll post an update. Thanks!
    – blunders
    May 22, 2014 at 18:53
  • Appears that the official response, which was posted as an answer, was that me deleting the default job allowed the read-only user to escalate their privileges and that I need to lock-down the default read-only user profile beyond the default settings; posted a question related to that topic here: How to I secure the Nonprofit Starter Pack from the Salesforce Foundation?
    – blunders
    May 22, 2014 at 20:19

I did a search on github for the name of the batch class in your screenshot, and found it here, in the NPSP github repo: https://github.com/SalesforceFoundation/NPSP-UM/blob/50f309bc70959d3044287fe9a98fa47e37e438a5/src/classes/RecurringDonationsSettings.cls

in the controller for a VF page called RecurringDonationsSettings. At a glance, it looks to me like that page will run those batches. I'm guessing your user found that page and did the thing that causes the batches to run. If they got there through the tab, I would remove access to the Recurring Donations Settings tab.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .