SOQL Datatable - When passing selected records from flexipage to flow, include fields from parent (lookup) records

[solo-1234]

When a soqldatatable is embedded on a flexipage, with buttons configured to call a flow and pass in the selected records as a collection, it would be useful if the flow could access fields on parent objects.

For example, if a datatable shows a list of Contacts, when passing them to a flow I'd like the flow to be able to access Account fields (the same as if the Contacts were fetched using a Get Records). This way, when looping through the collection of Contacts, I could use something like {!Loop_thru_Contacts.Account.Website}.

The same goes for custom objects, let's say my object has a lookup field to Contact, I'd like to use {!Loop_thru_records.Contact__r.Email} within a loop.

If it helps performance, I'd be open to specifying in the configuration which lookup fields I'd want to reference that way, so that it doesn't need to include fields from every lookup object on the record.

Let me know if any more details would be helpful. Thank you!

[tsalb]

@solo-1234 based on our chat in discord, my understanding is you've attempted this with a custom data model (not standard objects).

In your looping example - is it:

{!Loop_Thru_Custom_Object_One.Lookup_to_Custom_Object_Two__r.Email_Custom_Field__c}

With the relevant sobject crawling:

Custom Child => Custom Parent => Custom Field on Parent (1 relationship level level above only)?

[solo-1234]

In my case it's actually two standard objects with a custom lookup field between them. But standard/custom shouldn't matter I think. As I implement the datatable in more places I'm sure I'll have more situations where I want to pull in data from parent fields.

I was looking to go up one relationship level this time. But the ability to go further would probably be useful too!

[tsalb]

But standard/custom shouldn't matter I think

It does for my purposes - I'd like to understand your specific use case first - and then expand on other usages.

I have some code in there (unrelated, but i need to bring it into my considerations) that evaluate custom vs standard objects and their relationships.

If you can, please detail out your usage of relationships and if they are custom/standard ;)

[solo-1234]

Okay not a problem. So right now I'm using it on Opportunity, with a custom lookup field to Contact called Contact__c (or Contact__r).

[solo-1234]

But I don't want to commit to only needing it on that relationship :)

[tsalb]

Yep absolutely, i want to understand your specific use case and then expand on it, there's quite a few permutations but I figure i'd tackle yours first and then deal with the permutations later.

So to recap:

{Loop_thru_opp.Contact_Custom_Lookup__r.Email_Standard_Field}

So Standard (Child) > Custom Lookup (Parent) > Standard (Data Property)

Thanks!

[solo-1234]

If you want it to EXACTLY match my flow, I'm doing {Loop_thru_opp.Contact__r.FirstName} and {Loop_thru_opp.Contact__r.LastName}
Thank you!

[tsalb]

FYI this is why i want to be absolutely exact!

Contact.FirstName, Contact.LastName will behave differently than if you tried to loop Contact.Name (since Name is a compound field).

Though, I don't think this specific code will care, there are other parts of the code I calculate compound name differently. Still, the more information with regards to debugging and feature building - the better.

[solo-1234]

Aha! I didn't bother trying with Contact.Name because I didn't know if it would work.

[tsalb]

Me neither, for that matter - but now it's going to be part of my debugging process lol

[tsalb]

I have confirmed that when passing data from soqlDatatable on flexipage directly to flow, it loses parent fields despite querying them in the original soql such as:

SELECT Name, Amount, Contact__r.Name FROM Opportunity WHERE Contact__c != null

And setting up SelectedRows as an Opportunity Record Collection, it allows for autocomplete in lookup like so:

But you are hit with this error via email (didn't set up a fault screen):

The flow failed to access the value for Loop_thru_Opp.Contact__r.Name because it hasn't been set or assigned.

Given the example above, I have queried for Contact__r.Name but not Contact__r.LastName so I would expect it to fail on the latter, but not the former.

Additionally, I looked at the selectedRows output from soqlDatatable right before it goes to flow and it does not currently throw away any lookup fields (e.g. Contact.Name) so my only assumption is that Flow itself throws it away when you use a Record Collection as an input variable to flow.

So then, this looks like a limitation of LWC => Flow Engine handoff.

I also briefly investigated what it would take to basically do a Get Record IN Collection and looks like there is no easy solution for that. See this idea: https://trailblazer.salesforce.com/ideaView?id=08730000000DlzeAAC

In other words, there doesn't seem to be any workaround short of building a custom Apex Invocable (Get Record IN) or waiting for Get Record to receive an IN clause and pass it the SelectedRows input variable.

[tsalb]

For now, adding the wont-fix since this is now, I believe, a limitation of the Flow Engine when ingesting a Record Collection variable as a flow input (throws away all parent fields) and a separate, related, limitation of Get Records not allowing users to do IN clauses on either sObjects or recordIds.

[tsalb]

I would suggest raising another issue and reference this one, something to the effect of:

Apex Invocable - Get Records IN which itself references this idea

I have no idea on the feasibility of that, but that thread would be spent investigating both feasibility and LOE, if I or someone else were to pick it up.

[solo-1234]

Thanks for doing all the research! I'm going to attempt to build that action.