function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
PritzlPritzl 

Assignment/Trigger Precedence

Hello all. Still muddling about and hoping someone can point me in the right direction.

Summary:
I have set up a "before insert" trigger for cases generated through Web-to-Case. (different recordtype) It's purpose is to lookup the Account/ContactID based on a number of fields in the web form. (SuppliedCompany, SuppliedEmail, etc...) On successful lookup, we want to assign the case to the appropriate owner of the associated Account. Otherwise, the case gets assigned to a special queue set up to handle these "orphaned" cases.

Everything works fine at the trigger/Apex class level. I confirmed by sending myself an email with the retrieved values and checking the data objects with sForce Explorer. However, no matter what I do, I cannot get the case OwnerId value to "stick". It keeps getting reset to the Default Case User's Id or whatever User/Queue is specified in the Assignment rules. I'm not sure why this is so because based on the update sequence here: http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_triggers_order_of_execution.htm
assignment rules are processed after all triggers. i.e. it seems that the assignment rules on our sandbox over-write the looked-up OwnerId value.


Code:
public class WebCaseLookup {

public static void Execute (Case[] webcases) {
for(Case acase:webcases) {
String accountId = '';
String contactId = '';
String ownerId;
Account[] a;
Contact[] c;

// look up the contact based on the supplied email address
c = [select id, AccountId from Contact where email = :acase.SuppliedEmail];
if (c.size() == 1) {
contactId = c[0].id;
accountId = c[0].AccountId;
// now get the account's owner
ownerId = [select OwnerId from Account where id = :accountId][0].OwnerId;
}
// otherwise, try matching the account on the name
else {
a = [select id, OwnerId from Account where name = :acase.SuppliedCompany];
if (a.size() == 1) {
accountId = a[0].id;
ownerId = a[0].OwnerId;
}
}

if (contactId != '') {
acase.ContactId = contactId;
}

if (accountId != '') {
acase.AccountId = accountId;
acase.OwnerId = ownerId;
}
// jsut a test custom field to check that the update is actually working
acase.Greg_Test__c = 'UPDATED';

//just an email routine for debugging purposes
//Notify('APex Code results', 'Apex code ran successfully and found ContactId ('+contactId+'), AccountId ('+accountId+') and OwnerId ('+ownerId+')');

  }
 }
}

 

BunnyBoyBunnyBoy
If the assignment rules are run after the trigger fires, it sounds like they should overwrite your assignment.  According to the help content, cases created through web-to-case are always assigned with assignment rules, so it may not check to see that you have already assigned that value.  I haven't tested this, but if you don't find a more elegant solution, perhaps you could insert a new case with the same values as the incoming case and assign that one to the appropriate user, then use addError to prevent the original case from being created. 
 
Good luck.
PritzlPritzl
Thanks. That does make sense and I think I ran across that caveat on web-to-case somewhere too. Your solution sounds reasonable. I'll give it a try and report back.

Cheers...


Message Edited by Pritzl on 02-16-2008 09:12 AM
PritzlPritzl
Just reporting back. That particular workaround did not work.

After talking to SF support, we came up with an alternative. We created a custom field in which we inserted the id of the Account owner. Since it is a custom field, it doesn't get over-ridden in the assignment process. This was then coupled with an Apex class triggered by an "after insert" trigger on the case object that notifies the Account owner by looking up their email based on this custom field.

On a related note, where does one post new feature requests? It would have been real handy if there was some way to prevent the auto-assignment from kicking in.