5 Things That Could Give Your Custom Salesforce Apex Code Hiccups

Have you ever received a complaint from a Salesforce User about an unfriendly error message like, “Apex trigger Task caused an unexpected exception, contact your administrator: Task: execution of AfterInsert caused by: System.DmlException: Update failed. First exception on row 0 with id 00Qi00000023zxyzAB; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION, Please Enter Website.: [Website]: Trigger.Task: line 80, column 1“?  Or a complaint about some mystery duplicate records? Well, your Users probably experienced some hiccups from your custom Apex code.

If you are not quite sure where to look for the issue, I have a list of 5 common things that could cause your custom Apex code hiccups.

1. Validation Rules

The sample error message above was from a Lead Validation Rule, and it is easy to tell because it mentioned something about Field Custom Validation Exception.  This type of error usually occurs when you have a Custom Apex Trigger that Updates or Inserts a different Object after the current Record is inserted or updated (i.e. a Task Trigger that updates Status of the Lead in the Name Lookup field), or a scheduled Batch Class that updates records of the object that has Validation Rule enforce (i.e. a Batch Class that updates Accounts Type every night).

There are a few workarounds that you can do:

• Before you go to your Developer, you might want to consider making the field required only on the page layout instead.
• Update the validation rule to fire only when the required field is blank and the field that is being updated from the trigger is not changed (For example: ISBLANK(Website) && NOT(ISCHANGED(Status)) — Lead Status is the field that will be updated from the Trigger)
• Ask your Developer to make the error look friendlier.
• If you have a Batch Class, check with your Developer to see that the Class calls a DML operation inside Database class and opt_allOrNone is set to false (for example Database.update(theLeads, false)). If you specify false for opt_allOrNone parameter and a record fails, the remainder of the DML operation can still succeed.

2. Set a field to be Required by Default

I’m not a big fan of making a field required by default because it could cause error in many areas, such as Data Loader, Web to Lead, and Apex Trigger.  An error message from Required Field is a little bit different than one caused by a Validation Rule; it will tell you that a Required Field is missing and the name of the field (REQUIRED_FIELD_MISSING, Required fields are missing: [SIC Code]: [SIC Code]). This error will happen the same way as a Validation Rule and I really strongly recommend making the field required only on the page layout.

NOTE: Adding a Validation Rule or a Required field also can cause your current unit tests to fail and this will prevent you from deploying a change set or new code from any developer environment.

3. Workflow Rules

Workflow Rule Field Update usually causes data duplication, especially, when you have a Trigger that creates a new record after the record is inserted or updated. Basically the Trigger fired once when the record was inserted/updated and fires again when the Workflow Rule updates the record. My suggestions:

• Implement a Controlling Recursive Triggers technique to your code. There is a useful article in Developer force that you can use to prevent the Recursive Triggers.
• If you already have a lot going on in the Trigger, you might want to deactivate the Workflow Rule and update the Trigger to do the Workflow’s job.

4. Field Length

Salesforce does a good job of giving a warning when you try to change properties of a field, like changing the field label, name or reduce field length size, but you can ignore the warning and make the change anyway.  With the name change, Salesforce will give you an error if the field is referenced in Apex class or trigger, but you won’t get any error when you shrink the field length.

If you have a Trigger that populates a value with longer size than the field length, you will get an error like this “Apex trigger Task caused an unexpected exception, contact your administrator: Task: execution of AfterInsert caused by: System.DmlException: Update failed. First exception on row 0 with id 00Qi0000003Ce12dfg; first error: STRING_TOO_LONG, SIC Code: data value too large: 111111111111111 (max length=10): [SICCode__c]: Trigger.Task: line 81, column 1“.

My solution is Don’t Reduce Field Length.  It is OK to increase the Field Length though (it is better to have too much than too little).  It is also a good idea to write down a field description in the field properties; it can be something like “This field value is auto-populated by a trigger.  Please do not make any change.”

5. API Limits

If your organization has a custom button that calls a WebService and also has a third party app that syncs your Salesforce data and its data via API, you might run into API Requests limits exceeded.  This error will popup from a JavaScript error.  The message will look like this “{faultcode:’sf:REQUEST_LIMIT_EXCEEDED’, faultstring:’REQUEST_LIMIT_EXCEEDED: TotalRequests Limit exceeded.’, }“.

There is no ideal solution for this error, but you can try to reduce the numbers of API calls between your Salesforce Org and the Third Party app.  Otherwise, your users have to wait 24 hours before they can use the button again. To check your organization’s API usage, go to Setup > Administration Setup > Company Profile > Company Information.

Still got a hiccup?  Post your error below and let’s help you find a solution!