Using Apex: Create Task for an Opportunity

Let me be straight for you SFDC configuration vs. coding fanatics – I am in your group. I prefer point & click configuration any day as compared to the complexity that Apex can become. The example here deals about creating a task due to my lack of imagination rather than anything else – it is just another problem that can be addressed using Apex.

In a previous post, you had seen different ways of creating a task when a field is updated in Opportunity. If you have directly landed on this page, that post will tell you that there are other (possibly better) ways of handling this job.

Now, let’s get down to business.

The problem itself is simple – create a task when an opportunity is lost.

What follows is a rant of how a typical developer would go about it. We are going to create a trigger, which enables you to create your own actions that can follow a salesforce data manipulation (update, insert, delete).

 

Version (-3): The simplest trigger

Create a simple trigger that will create a task when Opportunity Stage is updated.

Does the trigger do its job? You bet it will.

 

So, what is wrong?

The code considers trigger.new[0] – assumes that there is only one opportunity updated at any time. The Task is created only for the first Opportunity if there are multiple opportunity updates happening in the same transaction.

By now you also understand the wierd version, huh?

 

Version (-1): Trigger that considers multiple record updates with the right conditions

Improve the previous version with provision to accommodate multiple opportunities in one go.

 

What is wrong?

  • oOptyList is not really needed – it would have made sense to use the query context when an entity other than Opportunity was used.
  • If there are too many records to be updated in the transaction, you will run the risk of hitting the heap size limits.
  • Creation of new task continues to happen in a loop

 

Version (0): Simple trigger that considers multiple record updates

Account for bulk updates and streamline task creation.

Also, check whether the StageName is indeed updated. You should not created duplicate tasks when updates are carried out on a lost Opportunity.

 

The for-loop ensures that 200 records are processed at a time. More importantly, the ‘insert task’ DML is placed outside the loop.

What is wrong?

  • You cannot really predict the sequence if there are multiple triggers
  • Recurrence due to updates in workflows or by other means can create duplicate tasks

 

Version (1): Use Trigger Classes!

All the goodness of the above with a standard pattern thrown in. I am not saying that this is the **only** way to promote reuse and standardize triggers, but is certainly one of the good ways to do that.

 

Now, for the class.

 

Of course, this is more complex than the earlier versions. But you can also see that –

  • code is modular and has high reusability outside the trigger context
  • it is easier to control what logic gets executed and when
  • easily test the classes
  • you can just manipulate the class and be 100% sure that the logic gets executed in the intended sequence

Also note that complexity of triggers grow over time. Although it is easier to write multiple triggers with 2-3 lines of code, that will present an overall spaghetti mess when trying to scale the application.

 

Version (2): Use Centralized Trigger Dispatch

The next version is to centralize the trigger dispatch for multiple objects.

That will come in later versions – one step at a time, amigo!

Leave a Reply

Be the First to Comment!

Notify of
avatar
wpDiscuz