0

I have a simple trigger to update standard Account field from custom field (b/c of Lead conversion mapping limitations). I want to move the update out of the loop and use a database.update(newAccount,false); so as to avoid trigger erros blocking inserts. See updated trigger...

 trigger AccounTypeUpdateFromLead on Account (before insert) {


   for (Account NewAccount: System.trigger.new){

   if(newAccount.type == NULL && newAccount.Lead_Account_Type__c!= null){

        newAccount.type =newAccount.Lead_Account_Type__c;

       }

    if (newAccount.parent == NULL  && newAccount.LeadParentId__c != NULL){

        newAccount.parent = [select id from Account where id =: newAccount.LeadParentId__c];



    }  

   }

}
2
  • Why are you trying to circumvent validation...that's not very consistent business logic. And you certainly don't need to re-query an Account to get its Id if it's already specified elsewhere. Just copy it over.
    – Adrian Larson
    Commented Jan 17, 2017 at 17:25
  • the field LeadParentId__c is text. It could be a lookup, then I'd be copying over to another lookup, but i didn't want to duplicate the relationship. i really just want to store that data.
    – jaw999
    Commented Jan 17, 2017 at 17:30

3 Answers 3

2

Clicks not code! Workflow Rule is the proper tool for the job here unless you absolutely need your field update to occur earlier in the execution order.

When to Click Instead of Write Code

Reinventing The Wheel

Let’s face it, as Salesforce developers we aren’t really all that different from other developers – we love to write code! And just because we can, we sometimes write code for things that could have easily been solved without coding, or we use our skills to address even the last tiny functionality or usability gap in a standard page… and end up writing a complete new custom user interface and maybe even framework along the way.

While custom development sure is a lot of fun – after all we’re developers and that’s what we do – the question is whether it’s really such a great idea to always dive straight into code when customizing Salesforce or building a new app on the Salesforce platform. Force.com started out as a declarative development platform in its early days and continues to provide a rich set of declarative development features to this day, so let’s dig in and find out what we can (and should) do with clicks instead of writing code.

Yours is the very first use case listed, even:

Examples for Declarative Development versus Code

Here are some use cases and examples for functionality that can easily be build declaratively, without writing a single line of code:

  • Instead of writing Triggers, we can automate Field Updates using Workflow – automatically populating a field with a default value or updating a field based on the value of another field is a pretty common requirement. Workflow can address the basic use cases just as well as writing an Apex Trigger.
6
  • Is parent Account updatable by workflow? i am not seeing it.
    – jaw999
    Commented Jan 17, 2017 at 17:25
  • I believe lookup fields can only be set declaratively via Process Builder. That field wasn't in your original question so I didn't see it...
    – Adrian Larson
    Commented Jan 17, 2017 at 17:26
  • Right, i see now how i could do the original with workflow, though it would take 1 rule per picklist option.....
    – jaw999
    Commented Jan 17, 2017 at 17:29
  • No...I don't think that's correct. You should be able to do it all with one rule.
    – Adrian Larson
    Commented Jan 17, 2017 at 17:32
  • Right, process builder can reference the picklist field, so all one rule. Many thanks
    – jaw999
    Commented Jan 17, 2017 at 17:51
2

As you can see here, there is no update allowed on a before insert trigger.

The main reason is that if you modify some fields of the Account objects in the Trigger.new list, the values are updated.

So you don't need an update.

5
  • Gotcha... but I feel this is still fragile and prone to error blocking an insert.
    – jaw999
    Commented Jan 17, 2017 at 16:02
  • Do you mean that some erros are raised when you insert an account? Commented Jan 17, 2017 at 16:04
  • I mean that if an error will block insert, rather than allow insert and just not change the Type.
    – jaw999
    Commented Jan 17, 2017 at 16:06
  • I'm sorry I don't understand what do you mean. Commented Jan 17, 2017 at 16:09
  • 2
    @jaw999 There's no possible error here you could possibly run in to. It's fine just the way it is.
    – sfdcfox
    Commented Jan 17, 2017 at 16:11
0

Triggers running on events "before" don't require explicit call of update dml for records in context of the trigger. This will cause infinite recursion.

Here you want to prevent any errors which can halt other successful operation so, instead writing database.update(newAccount,false) in trigger you should write on the place from where you are performing the update. Write database.update(newAccount,false) in the code which is causing the trigger to fire.

If this is from UI, leave it as it is you cannot suppress the error.

You must log in to answer this question.

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