7

This is driving me crazy because I JUST did this a month ago.

I have a simple apex class that exposes an invocable method so that I can call it from process builder:

public with sharing class SuperSimpleInvocable {
    /**
     * Inner class used to wrap a Lead object so that it can be invoked through Process Builder
     */
    public class InvocableVariableLead {
        @InvocableVariable(label='Lead' required=true)
        public Lead theLead; 
    }

    /**
     * InvocableMethod implementation that can be invoked through Process Builder
     */
    @InvocableMethod
    public static void invocableMatchLead(List<InvocableVariableLead> leads) {
        List<Lead> theLeads = new List<Lead>();
        for (InvocableVariableLead ivl : leads) {
            ivl.theLead.Comments__c = 'changed';
        }
    }
}

The problem is that when I create a process on the Lead object in Process Builder, when I attempt to call this class I'm not given the option to pass the Lead that's being acted upon. Here's what I'm getting:

enter image description here

Only 1 "Type" is available (Reference), and when I click in the "Value" box I get this:

enter image description here

As I said, I JUST did this with another process/apex class a month ago and I was able to get [Lead] in there. I even still have the process - the apex call looks like this:

enter image description here

Did something change? Am I missing something?


UPDATE:

I figured out a workaround for this scenario, however I'm still frustrated that things are working differently.

I changed my class to this:

public with sharing class SuperSimpleInvocable {
    @InvocableMethod
    public static void invocableMatchLead(List<Id> leadIds) {
        List<Lead> theLeads = [select Comments__c from Lead where Id in :leadIds];
        for (Lead l : theLeads) {
            l.Comments__c = 'changed';
        }
        update theLeads;
    }
}

And then my process invoked it with the following settings:

enter image description here

0
3

Do you actually need the InvocableVariableLead inner class with the @InvocableVariable annotated member? According to InvocableMethod Annotation a list of any sObject type (except the generic sObject itself) should be supported.


I modified the invocableMatchLead method to take a collection of Lead sObjects directly.

@InvocableMethod
public static void invocableMatchLead(List<Lead> leads) {
    List<Lead> theLeads = new List<Lead>();
    for (Lead l : leads) {
        // Do Something
        //l.Comments__c = 'changed';
    }
}

I was then able to configure calling this method from a scheduled action. enter image description here

5
  • Yeah - that's what I ended up doing, however I'm still fairly frustrated that doing things the other way doesn't work now. I remember struggling with things when I first implemented this because I couldn't get it to work WITHOUT wrapping the Lead object in a class with an InvocableVariable annotated field. So I went through all the trouble of doing it that way, and then when I needed to do it again I find that it won't work that way anymore. – cpfrommer May 17 '15 at 23:25
  • I've only been doing Salesforce development for a few months now (java dev for ~15 yrs), but I've already run into a number of... "situations" where something is fishy. The Queueable interface being enabled in some instances and not in others was another one - and i remember at some point it didn't work if you capitalized the Q in your code! It just seems like new features/functionalities can be a little wonky for the first couple months - I feel like I'm beta testing. – cpfrommer May 17 '15 at 23:34
  • @cpfrommer That's pretty much my experience with any technology/platform. The first release is going to have some issues that only come out at scale. Salesforce has its share of these just like everyone else. Keep an eye on the Known Issues to see what is changing. E.g. Invocable Apex actions with List inputs throw an exception on bulk update – Daniel Ballinger May 17 '15 at 23:49
  • @ Daniel Ballinger- I won't say that I haven't occasionally run into weird issues with other technologies, however the frequency seems a lot higher with Salesforce. Maybe it's just bad luck for me. Side note - I'm not a huge fan of sandbox/test instances behaving differently than production systems. Not only does one have to keep on top of the Known Issues, but also in which instances they're present, and whether or not one's production system will behave differently than the system one is deploying from. – cpfrommer May 18 '15 at 13:41
  • @cpfrommer I get your frustration, really. However, discussing the pros and cons of Salesforce isn't really the function of this sites comments :). Have we addressed the specific question of passing the Leads to the Apex class from a flow? If so, please use the tick so the question shows as having an answer. – Daniel Ballinger May 18 '15 at 21:31

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.