Background: I've been building a Lead round robin system to evenly distribute work. It checks for records owned by queues, and assigns them to the next user available in each queue. I opted to do a lot of work before insert, so that I could shuffle records around without extra DML.

However, I (incorrectly) assumed that Lead Assignment Rules happened much earlier in the order of execution, so none of my before insert code is finding any records in a queue. I didn't realize at first, because I had similar code in the before update logic which was catching the records that I thought were being handled before insert, so things appeared to be working in tests, until I started building my assertions.

This got me thinking of the following question:

Considering the Order of Execution (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm), Before and After triggers all run PRIOR to Assignment Rules. Workflows and Process Builders also run after the before triggers. Since Assignment Rules count as a workflow field update, before update and after update triggers run one more time after the record has been assigned to the queue, which is when my code actually picks them up and runs it through round robin.

When a user creates a record themselves, they own it by default. Even if they check the box to run active assignment rules, it follows the same order. It will always run before triggers prior to any other updates that would change the ownership to a queue.

So, assuming SF doesn't change this order - Is it safe to say that it is 100% impossible for a record inserted manually through the Salesforce UI (specifically) to ever be owned by a queue BEFORE INSERT?

2 Answers 2


Given the following axioms, it is 100% guaranteed impossible that the Owner would be a Queue.

  • The record is created manually through the User Interface.
  • There are no before insert triggers that alter the OwnerId.
  • The records are not imported through an API or Import Wizard.
  • The records are not created through code.

Once you start customizing Salesforce or using more advanced features, this would no longer be true.

  • Fox can you clarify this last bit "Once you start customizing or using more advanced features". The advanced features you are referring to I assume are API and Data Load/Import inserts? I already know that those methods would allow me to insert a record directly in queue (which justifies me keeping my Before Insert logic), just wanted to make sure there were no other non-programmatic ways to have a record START in a queue when entered by an end-user. May 14, 2019 at 12:25
  • @MorganMarchese Yes, that's what I meant to imply. Short of programming or using API calls, it is 100% impossible for any record to start in a queue by the time a before insert trigger fires.
    – sfdcfox
    May 14, 2019 at 12:27

Is it safe to say that it is 100% impossible for a record inserted manually through the Salesforce UI (specifically) to ever be owned by a queue BEFORE INSERT?

A before insert would mean that the record hasn't been saved yet to a database. The record comes to existence in the database only once the before insert triggers have been executed. Depending on when you are assigning the Owner for the record, the value will come to existence only when you have a record in the database.

So theoretically there is no way that a record which is not yet in existent to be owned by a Queue unless you assign the Owner's value during the operation as a Queue.

  • That is true, but even in the before insert context there is an OwnerId assigned to the record, even if it is still only a record in memory and not yet committed. My question was less about whether it exists in the DB and more about whether there was some SF native "clicks-not-code" method to insert a record directly into a queue outside of an API or Apex transaction. Sounds like the answer is no. May 14, 2019 at 12:23
  • Even if say you have an OwnerId assigned during before insert operation, the record will get into the queue only when it gets persisted. As long as it's in memory, it cannot be owned by the queue/or any other owner. So yes, the answer to your question is no.
    – Jayant Das
    May 14, 2019 at 12:27

You must log in to answer this question.

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