2

I've got some code that was failing when Pardot would hit a trigger on the lead object. The problem is that the "Pardot" user is not a real user that can be queried. It gets a valid running user Id, but apparently the user record doesn't exist. So:

Id runningUserId = UserInfo.getUserId();
// runningUserId is a valid user id
User u = [SELECT Id FROM User WHERE Id = :runningUserId LIMIT 1];
// if managed package like pardot is the running user then u == null

solved this by just adding a check to make sure that the user != null, but trying to understand more about this intangible managed package user. When is code actually running as this user? Specifically having issues with Pardot, but saw this same thing coming from Rollup Helper as well. Maybe something to do with scheduled jobs?

5

Any jobs that are executed as a result of installing, upgrading, or a push upgrade are run as this "package user", as well as certain automated actions. I know there's documentation on this user[citation needed], but basically, it is never safe to assume that you will receive a user back when you query based on UserInfo.getUserId().

| improve this answer | |
  • Thanks! Updated the code with a null check in case it's running in this context where the user doesn't exist and working properly. Still trying to find any documentation on this user and haven't been able to track anything down. – Jake Hebert Apr 27 at 16:40
  • Something else to consider, if a package install creates async jobs, i.e. sync runs, those jobs will continue to run in their context, so stuff that doesn't seem to fit into the list of installing/upgrading/pushing can end up in that context. Either way, you want a null check. – Ralph Callaway Apr 27 at 19:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.