LookupFSC filter function not working

[EdRedSled]

We are in a Sandbox (pre winter 21) and noticing the filter function in LookupFSC is not working (getting ALL records, not filtered records). For example, using a screen flow from Account to create an Opportunity with Contact Roles. We want to only see Contacts at that Account (recordId), but all Contacts are made available.

We were using LookupFSC from original 2018 install, then just downloaded the updated version and tried that, but same result.

(I am new to GitHub and this process, to feel free to "correct me" ask questions, etc. I'm not a developer)

[ericrsmith35]

Please post how you have the component configured.

[EdRedSled]

Hi Eric, this may fall into the "never mind" category....

Issue

• the LookupFSC filter works in Debug Mode, but NOT from the Action Button

Setup

• Action Button is linked to the activated Flow, and placed on the Account page layout
• recordId created - text, available for input, not multiple values (will pull in AccountID)

Flow Elements - Version 11 ( where the LookpFSC filter works in debug, but not from the Action button)

1. Get Account Record Type – Looks at Record Type to get an Account Record Type ID to be used later in the flow
2. Get Contact Record Type– Looks at Record Type to get a Contact Record Type ID to be used later in the flow
3. Screen - New Job Order (Opportunity) - collects field values to be used in next step.
4. Create Job Order Opportunity – uses Screen values and recordId to create opportunity and stores Opportunity ID in Variable “{!OppID}”
5. Get Job Order Opportunity Information – Filtered by {!OppID}, Only the first record and Automatically stores all fields, to be used later in the flow (and not documented here)
6. Create Opportunty Member – Creates Opportunity Team member using {!OppID}, Opportunity Owner ID and fixed values (Access Level and TeamMemberRole)
7. Screen – “Job Contact Lookup”
   • I1-Object = Contact
   • I2_Display Field = Name
     • I4_Outpout which field as a value = Id
     • I6_Filter on which field? = AccountId
     • I7_Filter Value = {!recordId}
8. And there is more to the flow, but the issue here is that the dropdown list of available contacts is properly filtered in debug mode, but when used through an Action button on the page layout it is NOT filtered.

So as I was writing this I reviewed some of my steps again and realized I could remove Step 1 & 2 because this flow is a copy of a similar flow originally intended to be used on a Contact. Once I removed step 1&2, it worked properly. So I am all set now, and I still have both version should there be any follow up questions.

At one point I thought it may have been related to the Known Issue below, which reports an issue with passing the recordId into the Flow (and is effecting me on other flows)

https://trailblazer.salesforce.com/issues_view?id=a1p4V000001lz3IQAQ&title=winter-21-list-button-does-not-pass-selected-record-ids-to-flow-and-visualforce

[ericrsmith35]

Thanks for the update.

On Tue, Sep 29, 2020 at 1:32 PM EdRedSled notifications@github.com wrote:

Hi Eric, this may fall into the "never mind" category....

Issue

• the LookupFSC filter works in Debug Mode, but NOT from the Action Button

Setup

• Action Button is linked to the activated Flow, and placed on the Account page layout
• recordId created - text, available for input, not multiple values (will pull in AccountID)

Flow Elements - Version 11 ( where the LookpFSC filter works in debug, but not from the Action button)

1. Get Account Record Type – Looks at Record Type to get an Account Record Type ID to be used later in the flow
2. Get Contact Record Type– Looks at Record Type to get a Contact Record Type ID to be used later in the flow
3. Screen - New Job Order (Opportunity) - collects field values to be used in next step.
4. Create Job Order Opportunity – uses Screen values and recordId to create opportunity and stores Opportunity ID in Variable “{!OppID}”
5. Get Job Order Opportunity Information – Filtered by {!OppID}, Only the first record and Automatically stores all fields, to be used later in the flow (and not documented here)
6. Create Opportunty Member – Creates Opportunity Team member using {!OppID}, Opportunity Owner ID and fixed values (Access Level and TeamMemberRole)
7. Screen – “Job Contact Lookup”
   • I1-Object = Contact
   • I2_Display Field = Name
   • I4_Outpout which field as a value = Id
   • I6_Filter on which field? = AccountId
   • I7_Filter Value = {!recordId}
8. And there is more to the flow, but the issue here is that the dropdown list of available contacts is properly filtered in debug mode, but when used through an Action button on the page layout it is NOT filtered.

So as I was writing this I reviewed some of my steps again and realized I could remove Step 1 & 2 because this flow is a copy of a similar flow originally intended to be used on a Contact. Once I removed step 1&2, it worked properly. So I am all set now, and I still have both version should there be any follow up questions.

At one point I thought it may have been related to the Known Issue below, which reports an issue with passing the recordId into the Flow (and is effecting me on other flows)

https://trailblazer.salesforce.com/issues_view?id=a1p4V000001lz3IQAQ&title=winter-21-list-button-does-not-pass-selected-record-ids-to-flow-and-visualforce

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexed1/LightningFlowComponents/issues/497#issuecomment-700867419, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF4UHXYPIQZJ6ZL2J4DCXSLSIIK4VANCNFSM4R54WP7Q .

[EdRedSled]

Same thing again, but different Flow.

Issue

• the LookupFSC filter inconsistently filters when in Debug or when used with an Action Button (both in a Sandbox that is NOT Winter 21)
• This is fundamentally the same flow as before in concept, but different because it originates from a different object from the original example
• What IS different is I have examples showing inconsistent filtering results based on the record. Meaning record A will consistently NOT filter, whereas record B will consistently filter.
• Note, I’ve primarily used Automatically store all fields and am starting to question that as a general practice. In this case we filter by the AccountId which we get from a related Opportunity (Get Record – automatically store all fields)

Setup

• This is an applicant tracking system. (Possible is a custom object that is a kind of junction of data between an Opportunity and a Candidate (Person Account) and the Flow creates a Placement (custom object/record) when someone gets employed.
• Action Button is linked to the activated Flow, and placed on the Possible page layout
• recordId created - text, available for input, not multiple values (will pull in PossibleId)

Flow Elements

1. Flow originates from a Possible (custom object record)
2. Get Records – “Get Possibles Data” – filtered on recordId – Only the first record - Automatically store all fields
3. Get Record – “Get all Possibles to clone” – Filtered – All Records – Automatically Store all fields
   • theoretically unrelated to this issue. We collect all other Possibles (applicants) to then associate with a cloned Opportunity (so we can close out the opportunity as closed won for Einstein scoring)
4. Get Record – “Get Opp Data” – Filtered by the PossibleId (so we have things like AccountId to use a filter in the LookupSFC below) – Only the first record – Automatically Store all fields
5. Get Record – “Get Candidate Name” – Filtered by the CandidateID from the Possible record – Only the first record – Automatically store all data
6. Get Record – Get Job Contact” – (from Opportunity Contact Role) – Filtered by the OpportunityId
7. Decision – “Is Job Contact Found” – if Get Job Contact is empty it routes to:
8. Screen – “No Job Contact” where we display LookupFSC (so they can choose a contact we can relate to the opportunity in a Contact Role) o Object = Contact o Filter Field = AccountId o Filter Value = {!Get_Opp_Data.AccountId}
9. And the flow continues from there, but I am stopping here as the issue seems to be that the Filter Value is not being “enforced” in certain circumstances.

In the previous example, the LookupFSC filter was filtering on the {!recordId} where as this example is filtering from the AccountId which is acquired via a Get Records.

Is it possible that when one uses Get Records with “Automatically store all data” that there is some limitation to the ability to “drill” deeper into the record. For example, using Get Record on a Possible to get go to the related Opportunity to get the Account ID. Is that “too far”, even though the tool allows me to do so?

[ericrsmith35]

For testing purposes, try creating a variable for the Filter Value and setting it in an Assignment node right after the node in the flow that provides the value you are looking for. Then use that variable for the I7_Filter Value attribute.

Eric

On Thu, Oct 1, 2020 at 2:48 PM EdRedSled notifications@github.com wrote:

Same thing again, but different Flow. Issue • the LookupFSC filter inconsistently filters when in Debug or when used with an Action Button (both in a Sandbox that is NOT Winter 21) • This is fundamentally the same flow as before in concept, but different because it originates from a different object from the original example • What IS different is I have examples showing inconsistent filtering results based on the record. Meaning record A will consistently NOT filter, whereas record B will consistently filter. • Note, I’ve primarily used Automatically store all fields and am starting to question that as a general practice. In this case we filter by the AccountId which we get from a related Opportunity (Get Record – automatically store all fields) Setup • This is an applicant tracking system. (Possible is a custom object that is a kind of junction of data between an Opportunity and a Candidate (Person Account) and the Flow creates a Placement (custom object/record) when someone gets employed. • Action Button is linked to the activated Flow, and placed on the Possible page layout • recordId created - text, available for input, not multiple values (will pull in PossibleId) Flow Elements - Version 11 ( where the LookpFSC filter works in debug, but not from the Action button)

1. Flow originates from a Possible (custom object record)
2. Get Records – “Get Possibles Data” – filtered on recordId – Only the first record - Automatically store all fields
3. Get Record – “Get all Possibles to clone” – Filtered – All Records – Automatically Store all fields o theoretically unrelated to this issue. We collect all other Possibles (applicants) to then associate with a cloned Opportunity (so we can close out the opportunity as closed won for Einstein scoring)
4. Get Record – “Get Opp Data” – Filtered by the PossibleId (so we have things like AccountId to use a filter in the LookupSFC below) – Only the first record – Automatically Store all fields
5. Get Record – “Get Candidate Name” – Filtered by the CandidateID from the Possible record – Only the first record – Automatically store all data
6. Get Record – Get Job Contact” – (from Opportunity Contact Role) – Filtered by the OpportunityId
7. Decision – “Is Job Contact Found” – if Get Job Contact is empty it routes to:
8. Screen – “No Job Contact” where we display LookupFSC (so they can choose a contact we can relate to the opportunity in a Contact Role) o Object = Contact o Filter Field = AccountId o Filter Value = {!Get_Opp_Data.AccountId}
9. And the flow continues from there, but I am stopping here as the issue seems to be that the Filter Value is not being “enforced” in certain circumstances. In the previous example, the LookupFSC filter was filtering on the {!recordId} where as this example is filtering from the AccountId which is acquired via a Get Records. Is it possible that when one uses Get Records with “Automatically store all data” that there is some limitation to the ability to “drill” deeper into the record. For example, using Get Record on a Possible to get go to the related Opportunity to get the Account ID. Is that “too far”, even though the tool allows me to do so?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexed1/LightningFlowComponents/issues/497#issuecomment-702328957, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF4UHXZC72VMFTFFQY3APSDSITFHZANCNFSM4R54WP7Q .

[EdRedSled]

Brilliant. Same result and I can now see the Accountid field is definitely not populating... however now I realize why. Because there is no account on the opportunity!

This flow creates a clone of the opportunity, so with previous testing I seem to have unknowingly created opportunities without an account which caused the "issue" I reported. Obviously I need to fix that, but once I related the account to the opportunity the filtering worked properly.

Bottom line ID10T error... thank you for the sage advice.... back to the flow!

[ericrsmith35]

😵

On Thu, Oct 1, 2020 at 4:15 PM EdRedSled notifications@github.com wrote:

Brilliant. Same result and I can now see the Accountid field is definitely not populating... however now I realize why. Because there is no account on the opportunity!

This flow creates a clone of the opportunity, so with previous testing I seem to have unknowingly created opportunities without an account which caused the "issue" I reported. Obviously I need to fix that, but once I related the account to the opportunity the filtering worked properly.

Bottom line ID10T error... thank you for the sage advice.... back to the flow!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexed1/LightningFlowComponents/issues/497#issuecomment-702372839, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF4UHX2Y5J3BNUAB4EL7R2LSITPNZANCNFSM4R54WP7Q .