function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
jhartjhart 

InstallHandler - can I repurpose the app "User" for Scheduled Jobs?

The new-in-Summer-12 "InstallHandler" interface is a huge addition to Apex - thanks salesforce devs & PMs.

 

Question:

 

I note that the InstallHandler script runs as "special system user that represents your package".

 

Can I call System.schedule() within an InstallHandler to create a new Scheduled Job w/ that same user context?  If so, will it run successfully, or will it fail b/c that special app user no longer exists?

 

I recognize that I can find this out on my own, but rolling a package & installing it, etc, will take quite some time ... does anyone just know the answer?

 

Note - I really hope the answer is "you can create Scheduled Jobs with that User, and they work great!" because that would solve a major pain-point of applications like ours that require Scheduled Apex and are installed at the customer for years:  eventually, the User account associated with our Scheduled Job is deactivated, and then our scheduled job fails, and then we need to reschedule it with a new user ID ... until it is deactivated, etc.

Best Answer chosen by Admin (Salesforce Developers) 
jhartjhart

Answer: yes!  Seems to work; the CronTrigger is owned by the app pseudo-user, and runs just fine.

All Answers

jhartjhart

Answer: yes!  Seems to work; the CronTrigger is owned by the app pseudo-user, and runs just fine.

This was selected as the best answer
EJWEJW

The problem with this approach is that if your job updates a record that fires a trigger, say from another managed package or in-house custom code, and that trigger enforces sharing then an exception will be generated.  The pseudo user has no permissions to anything in the org when sharing is enforced.  I've already run into this in the wild with another managed package utilizing the pseudo-user for scheduled jobs.  Your scheduled jobs should really be run as a particular user that actually exists in the org.

 

Thanks,

jhartjhart
EJ,

That's good info, thanks.

From what you are saying, this is only a problem if a trigger enters into a "with sharing" block?

Across hundreds of installs we have never seen the behavior you are describing; however our Cron job is primarily concerned with our namespaced objects (which our users do not typically trigger on) vs. standard objects that might have a trigger which then enters a "with sharing" context.

For our particular use case, the pain of having to deal with CronTriggers scheduled as a deactivated user far outweighs the (potential) pain of a 3rd party trigger entering a "with sharing" context.

-john
EJWEJW

I've only run into the issue once myself in an org with a managed package installed that uses the pseudo-user for scheduled apex along with our managed package (DupeBlocker).  Both interacted with the standard objects and DupeBlocker enforces sharing by default when checking for duplicates, which caused their scheduled process to generate exceptions.  It was a pain to figure out.

 

Just thought I'd mention the issue.

 

Thanks,

jhartjhart
just sent you a PM.