Showing posts with label Apex. Show all posts
Showing posts with label Apex. Show all posts

Thursday, March 3, 2011

Leads, Campaigns, and Workflow

I have a requirement for a client that wishes to create a Web 2 Lead form and assign it to a campaign.
Once that is done, a workflow shall fire off a series of emails depending on what sort of campaign the lead is tied to.  This sounds easy enough to do with Salesforce's out of the box Web2Lead functionality and workflow, but there were some other tweaks we needed, so utilizing our own solution is the only way to go.

- The form -
Utilizing a jQuery modal, the user clicks a link and populates a small web to lead form.  When the user hits submit, sever side validation happens in a VF controller, so we can control the UI (messages and labels if a field is required for instance). 

- Allowing Portal users to use the web 2 lead form -
Once the form is submitted, it stores the lead in a custom lead object.  The custom lead object is needed, since leads cannot be created (owned) by Portal users.  When a portal user creates the mirrored lead object, it fires off a trigger calling an @future method to insert the lead and campaign member.

- Tricky workflows with Leads and Campaigns -
Here's the tricky part of the workflow.  When the lead is inserted, it doesn't have access to its related Campaign member and hence related Campaign (the Campaign member is a junction object to connect Campaigns to leads or contacts).  Our workflow needed to look at the Campaign Name field on the Campaign.  The lead doesn't have this when it is inserted, nor if the Campaign member is updated, does it update the lead.  Therefore, modifying the campaign member or campaign doesn't fire the workflow rule until the lead is updated next.  This is true even if the workflow rule is set to 'Created or did not previously meet the criteria'.

The solution is to create the workflow rule on the Campaign member and not the Lead.  When the Campaign Member junction is created, it should have access to both its Campaign and its Lead objects.  Thus, when the member is created, we can create a rule like 'Campaign Name equals My Name' and fire off a workflow when the Lead is assigned to the particular campaign.

Hope this helps others.

Monday, January 3, 2011

Force.com Labs Round Robin Record Assignment - Case Owner issue

There's an existing defect in the Salesforce package for Round Robin Record Assignment.  (http://appexchange.salesforce.com/reviews?listingId=a0N3000000178fsEAA).  The Force.com lab unmanaged package assigns Cases to an owner/queue when available.  The package contains two triggers which assign the case to an owner; caseRoundRobin.trigger and caseOwnerUpdate.trigger.

The two triggers inadvertently fight with eachother.  The fighting causes a Case to be re-assigned to it's original owner when it is first reassigned ownership. Say you have a case w/ owner John, and you want to reassign it to owner Mary.  In the Salesforce UI, after you save the ownership, it reverts back to John on the first attempt.  A second attempt will get you to the right owner, however.

The defect arises in caseOwnerUpdateTrigger.  After the code loops through the effected cases in the Trigger, via Trigger.new, it adds the cases to a temp list and then does a SOQL query to retrieve them once more via Id. The second loop does a query against uncommitted data and returns the yet unmodified owner of the Case, which would be John from the example above.  The case is then updated w/ the former Owner and appears the Case never changes hands.

The following change to the trigger should clear things up, consolidating everything into one loop, with no 'dirty', or uncommitted reads.

Two notes here: 1) Since the case in the loop is in process of being edited by the Trigger, it is locked and in read-only mode.  Therefore, a temp case is created and added to the update list.
2) The update call is made on the list of cases rather than on individual cases in the loop.  This is a Salesforce best practice, in order to mitigate SOQL queries and DML.

trigger caseOwnerUpdate on Case (after update) {
    List updateCS = new List();
    Map cases = new Map();
   
    for (Case cs : Trigger.new)
    {
        if(Trigger.isUpdate) { 
            System.debug('>>>>> Owner ID: '+cs.ownerId+' Temp Owner ID: '+cs.TempOwnerId__c);
            if(cs.TempOwnerId__c <> null && cs.TempOwnerId__c <> '') {
                if(cs.OwnerId <> cs.TempOwnerId__c) {
                    Case temp = new Case();
                    temp.OwnerId = cs.TempOwnerId__c;
                    temp.TempOwnerID__c = 'SKIP';
                    updateCS.add(temp);
                }
            }          
        }  
    }
 
    System.debug('>>>>>Update Cases: '+updateCS);
   
    //
    //Update last assignment for Assignment Group in batch
    //
    if (updateCS.size()>0) {
        try {
            update updateCS;
        } catch (Exception e){

        }
    }
}

Monday, December 27, 2010

Inheritance and Visualforce page controllers

Salesforce Apex is pretty finicky with inheritance in comparison to Java.
Even though it is Java based, there are many caveats, especially in inheritance and OO related principles.

In Visualforce, you have the option of denoting either a StandardController or Controller, in addition to controller extensions.  The extensions may or may not have code in common with the controller.  If they do, then you'll want to take advantage of inheritance and creating an abstract controller.

Below is a simple example of a Visualforce page utilizing an abstract controller.

Test.page:

<apex:page controller="Test" extensions="Test1,Test2,Test3">
<apex:form>
<apex:commandButton value="Go" action="{!go}" rerender="out" />
<apex:outputPanel id="out">{!output}</apex:form>
</apex:page>

Test.cls:
public abstract class Test {
  public String output {get; set;}
 
  private Test controller = null;
 
  public Test(){}
 
  public Test(Test controller){
      this.controller = controller;
  }
 
  public virtual void go(){
      output = 'Test';
  }
}

Test1.cls:
public class Test1 extends Test{
  public override void go(){
      this.output = 'Test1';
  }
  //Visual force needs this constructor to perform the controlling logic
  public Test1(Test test){ super(test); }
}

Test2.cls:
public class Test2 extends Test{
  public override void go(){
      this.output = 'Test2';
  }
  public Test2(Test test){super(test);}
}

Test3.cls:
public class Test3 extends Test{
  public override void go(){
      this.output = 'Test3';
  }
  public Test3(Test test){super(test);}
}

FYI, if you're reading through the Advanced developer study guide, 'Test1' is printed after clicking  the go command button.