0

I've a requirement that the Trigger should fire only when the Lead record is being entered through Slaesforce classic UI, Trigger should not be fire if the record is being entered by communities or from VF pages or through any other way. I am able to write a Trigger but it always fires.

trigger DupLead on Lead (before insert, before update) 
{
List<String> firstNameStr = new List<String>();
List<String> LastNameStr = new List<String>();
List<String> EmailStr = new List<String>(); 
// The for Loop is getting the new values which is being entered.
string uid = userinfo.getUserId(); 
 system.debug('ID of a user who invokes the Trigger' + uid);
//    ID userID = '0056E0000030XU6';
for(Integer index = 0, size = Trigger.new.size(); index < size; index++)
{

    firstNameStr.add( Trigger.new[index].FirstName.substring(0,1) + '%' );        
    LastNameStr.add( Trigger.new[index].LastName );                
    EmailStr.add( Trigger.new[index].Email );
    }    

List<contact>  dupCheck = new List<Contact>();     
dupCheck = [SELECT ID, FirstName from contact where  ( ( FirstName  like :FirstNameStr AND LastName = : LastNameStr ) AND  (   Email = :EmailStr  OR Alternative_Email__c = :EmailStr )  ) order by createdDate  asc ];    
system.debug('This is dupCheck Records  '+ dupCheck);
if( !dupCheck.isEmpty() )
{
    for(integer i = 0; i< dupcheck.size(); i++)
    {    
        Trigger.New[i].addError(Label.IBEN_Duplicate_Contact,False);    
    }     
}



  }
3
  • 1
    I dont believe Triggers are aware of the origin, imo, if the recor dis created via communities, you will need to do the validation client side using a custom component, same in your VF page
    – glls
    Aug 11, 2018 at 21:22
  • 1
    This seems like a bit of an X-Yish approach to duplicate management. Since triggers don't have an inherent UI context, you'll at least need to step back to define the requirements a little differently. Stepping back a little further to look at whether trigger-based duplicate management is the right approach at all might be more productive.
    – David Reed
    Aug 11, 2018 at 22:01
  • 1
    Adding to the above: perhaps your trigger could be set to fire based on the user's profile that performed the action. This will easily allow you to rule out community users. Aug 12, 2018 at 9:25

1 Answer 1

1

I see two problems here. One is with the approach, and one is with the code.

On the approach side, it's important to remember that triggers do not have an inherent UI context. A trigger may be fired by, for example, actions in a Platform Event trigger (context user Automated Process), an inbound web service (context user either the remote authenticated user or a Site guest user), a Process Builder or Flow (context user whoever started the automation, but no direct link to the UI), and so on. There's no meaningful way to determine whether a trigger is responding to actions undertaken in Classic, Lightning, a Visualforce page running in either experience, or a community.

That said, as was suggested in a comment, you can inspect the running user's profile and role and use those values to make decisions about functionality.

There is another issue with this specific code, though: it doesn't work the way you think it's going to.

dupCheck = [SELECT ID, FirstName from contact where  ( ( FirstName  like :FirstNameStr AND LastName = : LastNameStr ) AND  (   Email = :EmailStr  OR Alternative_Email__c = :EmailStr )  ) order by createdDate  asc ];    

if( !dupCheck.isEmpty() )
{
    for(integer i = 0; i< dupcheck.size(); i++)
    {    
        Trigger.New[i].addError(Label.IBEN_Duplicate_Contact,False);    
    }     
}

There's several core issues with this algorithm.

  • Your query mixes and matches criteria, so it won't work the way you need it to. Suppose you get in two Contacts with the names "F. Anderson" and "Q. Jones" (ignore Email for a moment). Your query will return records with names like "Q. Anderson" as duplicates.
  • The fields FirstName, LastName, and presumably Alternative_Email__c are not indexed (unless you've worked with Salesforce to change that), making this query potentially quite expensive if you have any data volume in the Contact object.
  • You are assuming that your returned Contacts list has the same count as Trigger.new; you have no reason to do so.
  • You block the entire transaction with a duplicate error if any "duplicate" exists, which will produce confusing errors and make (for example) Database.insert(list, false) and Bulk API loads far less useful.

To make this work the way you're designing it, you will need to do a good deal of post-processing work on your query results (probably building up a match key in a Map<String, Contact> from your First/Last/Email fields) and then iterate over the Trigger context variables to determine which are and are not duplicates.

I would recommend stepping back and considering native duplicate rules and other non-trigger-based duplicate management solutions before going down this path.

You must log in to answer this question.

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