1

I have two Objects : Activities and Services, with each field. I create a Trigger (Before Insert) on the Activity, in the Trigger I would like to modify the fields of a record of the Service object.

How can I do that?

  • What is the relation of these two objects(lookups? master-detail)? – highfive Mar 27 '14 at 9:22
  • In the Activity, one of its fields is a pick list of record of the Service object. When I made ​​an insertion of Activity I would like to increment a counter in the Services object. – Simon Gazin Mar 27 '14 at 9:37
4

Not much clear what your specific requirement is. In abstract, yes you can update other object's fields inside a trigger.

trigger MyActivityTrigger on Activity(before insert){
    List<Services> updateServiceList = new List<Services>();  //Use your correct API name for Services

    // See update below since this is not the best practice to retrieve other objects
    // inside a trigger      
    List<Services> existingSerList = [SELECT Id, Name, *etc* FROM Services]; //use a filter here
    for(Activity act : trigger.new){
        //your act tasks
    }

    //do whatever modifications to the other object
    for(Services service : existingSerList){
        service.Your_Field = Your_Value;

        updateServiceList.add(service);
    }

    update updateServiceList;
}

NOTE : to catch the correct Service records you need to include a filter in above. But note that if you are using a before update trigger, at the trigger context the Ids of the Activities are not populated.

UPDATE
Any object can be retrieved with SOQL in a trigger as usual. But the important point is you should maintain a set or map with related ids of the objects that are being triggered and put a filter in the SOQL of these other objects(to do this first you should have a relationship between them). Also it's a good practice to check for any field changes that the trigger is using for and after all these condition populating the set or map and then querying the other objects with the well formed id(or relevant field) collection. Then your code will doing minimum SOQLs and DMLs which needs to be.

| improve this answer | |
  • That's what I wanted to do, I think I can handle it. It will help me, thank you – Simon Gazin Mar 27 '14 at 10:16
  • Cool!. Glad to help you. – highfive Mar 27 '14 at 10:20
  • Should be included the Services Object in the Trigger? In my Trigger I want to display the existingSerList with System.debug, or when I run my Apex Class TEST, System.debug does not appear. But individually test the code works – Simon Gazin Mar 27 '14 at 13:59
  • If I understood correctly, you need to add some System.debug() in your trigger is it? As usual you can simply add debugs. e.x. System.debug('list size : '+existingSerList.size());. Sorry if this is not what you needed. – highfive Mar 27 '14 at 14:41
  • I'm hurting explain, System.debug is not a problem. I inserted one, into the loop for(Services service : existingSerList) for a test. But the result is empty : [DEBUG]List : List(). But when I execute the code in Execute Anonymous I have the complete list. (I work in Eclipse). I hope well explained. – Simon Gazin Mar 27 '14 at 14:56
1

Just want to flag a couple of things in highfive's answer that may be there because of the specifics of the question but are things that it would not be good for people to copy in general.

The first is that the trigger is always performing a query whether the information returned by the query is needed or not. With the number of SOQL calls being governor limited coding in that style is storing up trouble for the future. The better pattern is to first examine the data coming in through Trigger and collect the relevant data in maps or sets. Then only do the query if necessary. Often that examination would be to check if a specific field has changed and ignore other changes. But also see the next point...

The second is to note that standard objects are visible to all/most apps installed in an org. So if you add a trigger to a standard object you are potentially impacting other apps too and they are impacting your app. So where the standard object is associated with your custom object (e.g. an Attachment on your custom object) you should check the type of the id ASAP in your trigger (use getSObjectType) and do as little as possible if the id is not one that you are concerned about.

Bottom line is that as well as being set oriented, triggers should always do the minimum work possible. And this becomes critical if you are adding triggers to standard objects that are shared by all/most apps.

| improve this answer | |
  • My English is not very good, so I don't know if I understood correctly. To answer you, I work ONLY on custom object. And then I always do a Apex Test Class for code coverage, and I want 100%. Thank's for your precision – Simon Gazin Mar 27 '14 at 11:29
  • @SimonG. So your Activity/Activities is a custom object right? Fair enough. – Keith C Mar 27 '14 at 11:37
  • Yes, It has nothing to do with the standard object. My Object is XXX_Activity__c – Simon Gazin Mar 27 '14 at 11:40
  • Strongly agree with your point one @KeithC.I'm following those practices in my triggers but couldn't able to add them here when trying to answer to the question specifically as you thought. About the second point to be honest I haven't consider this earlier. Thanks for the point. – highfive Mar 27 '14 at 14:30
  • 1
    @highfive Thanks for your comments - yeah this question perhaps isn't the typical trigger situation. Would you mind adding the point to your answer that querying every time is not typical; might stop someone copying that when it shouldn't be done. Many triggers posted on this site are a long way away from "best practice". – Keith C Mar 27 '14 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.