1

Is it somehow possible to implement a process based on TASK creation, that accesses information on a related opportunity (if present)?

More precisely, I want to update a field on the task, if the account behind the related opportunity has a related_company field.

Meaning: Task.related_company__c = Task.Opportunity.Account.related_company

However, since Opportunity is not required on the task accessing it is not trivial. Any help appreciated!

Update:

For anybody wondering, how to access leads information. I created an invokable method and will trigger it on Task creation if WhoId starts with '00Q'. Find the method below:

public with sharing class ActivityCompanyFromLead {
    @InvocableMethod(label='ForActivityGetCompanyFromLead' 
                     description='If invoked, will check the lead for a related company and update the task')

    public static void getLeadInformation(List<Task> tasksToUpdate) {

        List<Task> tasks = [SELECT Id,Related_Company__c,WhoId
                            FROM Task
                            WHERE Id IN: new Map<Id, Task>(tasksToUpdate).keySet()];

        if(tasks.size() > 0) {
            List<String> whoIds = new List<String>();

            for (Task t : tasks) {
                whoIds.add(t.WhoId);
            }

            if (whoIds.size() > 0) {
                List<Lead> leads = [SELECT Id,Related_Company__c
                                    FROM Lead
                                    WHERE Id IN: whoIds];

                //create mapping from leadId to related company 
                Map<String,String> whoIdMap = new Map<String,String>();
                for(Lead l : leads){whoIdMap.put(l.Id,l.Related_Company__c);}

                for (Task t : tasks){
                    if(String.isEmpty(t.Related_Company__c) == true) {
                       ID related_company = whoIdMap.get(t.WhoId);
                       t.Related_Company__c = related_company;
                    }
                }

                update tasks;  

            }
        }

    }     }

Feedback is obviously welcome. Thanks a bunch to David!

1

You can, and because of special functionality on Task.AccountId you don't have to use the generalized solution, which requires either Apex or Process Builder + Flow to handle the polymorphic Related To field (WhatId). Instead, for this use case, you can get it done with Process Builder alone.

Process Builder Solution

Task has a lookup to Account as well (Account/AccountId). When the Task is related to an Opportunity, the Account is populated automatically with the Opportunity's Account. That's not the only source of population of the AccountId field:

If the value of WhatId is any of the following objects, then Salesforce uses that object’s AccountId.

  • Account
  • Opportunity
  • Contract
  • Custom object that is a [master-detail] child of Account

If the value of the WhatId field is any other object, and the value of the WhoId field is a Contact object, then Salesforce uses that contact’s AccountId.

This fact allows you to do a Process Builder-only solution when you want to do some work that involves a related Account.

Set up your Process on Task, when a record is created or edited. Set the criteria note to "Related To Id starts with "006", which will select Tasks related to Opportunities.

Then, add a Record Update action. Choose Related_Company__c on Task, and set its value to a Field Reference. Index through the Account Id node to get the Related Company field there, and you're all set.

Generalized Solution

When you don't get to take advantage of the builtin AccountId lookup, you have a somewhat more complex solution pattern that requires either Apex or Process Builder + Flow.

The basic logic is to inspect the WhatId to determine its type ('006' is the key prefix for an Opportunity, so a Process can have a criterion "Related To Id starts with "006", or you can look at What.Type in Apex) and then perform a query (Apex) or lookup (Flow) to find the relevant Opportunity and field, based on an Id that turns out to be an Opportunity.

I'd personally prefer to do this in an Apex trigger, because to me the Flow approach here is a little clumsy, but it's perfectly doable in Flow. You'd start a Process on Task update and have the Process inspect its WhatId to see if it's related to an Opportunity, and if so pass the Task's Id to an invoked Flow, which would implement the logic as above.

  • David!! Pleasure running into you again! This is such a wonderfully written answer. I actually managed to get the WhatId part working, but only for updating a related opportunity, not the other way round (i.e. updating the task with opportunity information). Do you happen to have a minimal example for flow/trigger? Assume I want to set the opportunity.account.related_company on the task (if it exists). – Fabian Bosler Aug 3 '18 at 15:57
  • @FabianBosler, updating the Task should actually be more straightforward than the Opportunity - you can use the Process Builder solution above, and when you create an Update Records action, select 'Update the Task that started the process'. Does that make sense? – David Reed Aug 3 '18 at 15:59
  • Unfortunately it isn't. The Opportunity update can be entirely done in the process builder, since the update record part allows for selection of a related object like this: [Task].Related To ID (Opportunity), however it does not allow to get a field value like this (at least thats my understanding). Would have to look something like [Task].Related To ID (Opportunity).Account.related_company__c – Fabian Bosler Aug 3 '18 at 16:03
  • 1
    You don't need to look at the value of Related_Company__c at all - you can just set Task.Related_Company__c to the value of Task.Account.Related_Company__c. Again, so long as you don't need to go down to the level of Task.Account.Related_Company__c.SomeField__c, where you could get a NullPointerException. – David Reed Aug 3 '18 at 16:16
  • 1
    Holy moly, this actually works ... crazy :) – Fabian Bosler Aug 3 '18 at 16:18

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.