Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

Flow Invocable Apex with Any Salesforce Object Type

02 Jan 2020 🔖 salesforce flow architecture
💬 EN

In case you missed it (hat tip to the “Salesforce Discord Abridged Release Notes” on my part), when working with a developer to build out snippets of “Invocable Apex” (kind of like sub-flows, but written in code) to run from your Salesforce flows, as of Spring ‘20 you can make them work on any Salesforce object.

Q: When will this be useful?

A: When you want to delegate business logic to code, and …

  1. Your logic doesn’t care about what fields exist on a given object (table) of your Salesforce org.
    • e.g. “Give me a random record out of this collection of records.”
  2. Your logic only needs to inspect fields that come standard with every object, such as Id or Name or LastModifiedDate.
    • e.g. “Give me the record, out of this collection of records, with the most recent LastModifiedDate.”
  3. Your logic only needs to inspect fields that you know you gave the same name on multiple objects (e.g. MyCustomObject1__c.MyCustomField__c and MyCustomObject2__c.MyCustomField__c), and you promise yourself you won’t try to pass the Invocable Apex records from any objects that don’t have a MyCustomField__c field.
    • e.g. “Give me the record, out of this collection of records (which I personally will always make sure are Leads or Contacts), with the most recent SubscribedDate__c.”

Q: When won’t this be useful?

A: When …

  1. Your business logic was too simple to delegate to code in the first place – you already have a flow developed and at the ready to be a “subflow.”
  2. Your business logic involves inspecting values from fields that only exist on one type of object in the first place (e.g. MyCustomObject__c.MyCustomField__c).
    • (In this case, just tell your Invocable Apex to expect MyCustomObject__c records like you’ve always been able to do! No SObject multi-object functionality needed in the first place.)

See the official Relase Notes for screenshots and a thorough explanation of the new functionality.

P.S. I haven’t fully thought it through yet, but this probably gets a little closer to Alex Edelstein’s dream of making it easy for admins who design Flows to leverage JSON.deserialize() in Invocable Apex to communicate with “APIs” from 3rd-party web sites.

I think just about the last thing that could be tweaked would be allowing Loop components to iterate directly over {!Invocable_Flow_Action_Name_Here} (or, in the case of a field that is itself collection-typed, {!Invocable_Flow_Action_Name_Here.field_name_here}), the way the output of a Get Records component shows up in the Loop’s “Collection Builder” picklist under “Record Collection Variables.”

Just in case you’re out there and see this, Alex. ;-)

--- ---