Apex Code Development You need to sign in to do that
Don't have an account?
jeremyy Fire assignment rules in update trigger
I'd like to run a lead through assignment rule after it has been created, using an after update trigger. The trigger below is a proof of concept, but the assignment rule does not run. I've seen other threads that indicate this should work. Can anyone confirm?
trigger LeadTrigger on Lead (after update) {
List<Lead> leadsToUpdate = new List<Lead>();
for (Lead l : Trigger.new) {
if (!l.AutomatedAssignment__c) {
Lead leadToUpdate = new Lead(
Id = l.Id,
AutomatedAssignment__c = true
);
Database.DMLOptions dmo = new Database.DMLOptions();
dmo.assignmentRuleHeader.useDefaultRule = true;
leadToUpdate.setOptions(dmo);
leadsToUpdate.add(leadToUpdate);
}
}
if (!leadsToUpdate.isEmpty()) {
update leadsToUpdate;
}
}
Nothing is jumping out at me there - does the assignment work correctly if you change the flag manually within the page layout?
Yes it does work if you manually change the flag, then save.
There seems to be something about the original transaction that prevents assignment from running.
The following are happening in the "transaction":
1) Email Services does an insert (ideally this would use assignment rule. it's managed code we don't control)
2) Workflow causes an update
3) The after update trigger performs an update, this time with use default assignment = true
4) Assignment should happen here, but does not.
Wouldn't be the first time I've seen a workflow and a trigger clobber each other. As a hail mary, you might try putting the trigger logic into an @future, which will occur in near real time but its own context. Might spare it from the workflow logic.
Thanks.. I'm going to avoid @future, which have too much baggage of their own. I'm going to write my own email handler.
Can you define what you mean when you say @future has too much baggage of its own?
Just curious.
Hi Ryan,
In this case, I was primarily referring to the limited number of future calls that can be made in a 24-hour period. I can't depend on usage being under this limit, and the resulting runtime exceptions would not be acceptable.