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?

Attribution to: Simon Gazin

Possible Suggestion/Solution #1

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.

Attribution to: highfive

Possible Suggestion/Solution #2

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.

Attribution to: Keith C
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/31053