Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flow - WF_Verifieer_gegevens_Eindklant_Bereikbaarheid - Lookup Resets #1539

Open
sserbanoiu opened this issue May 8, 2024 · 0 comments
Open

Comments

@sserbanoiu
Copy link

How to use GitHub

  • Please use the 馃憤 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Steps to reproduce

Steps to reproduce the behavior:

  1. Go to a case and start the Flow that contains the LookupFSC component
  2. introduce the birthdate in the lookup field

Expected behaviour

As soon as you introduce a part of the birthdate (eg. "1-1-1990", you don't really have to finish the year) a list of all the relevant contacts with the correct/ similar birthdate will appear
image](https://github.com/alexed1/LightningFlowComponents/assets/144791069/7681e5a8-95b9-446f-ac0b-5989c2f4aa30%22%3E)

Actual behaviour

In production environment, because of the large database of contacts that exists. The first time when you introduce in the lookup field "1-1-199" the relevant list appears, but then shortly it disappears, being reset to the initial list of contacts without taking into account the input.
image](https://github.com/alexed1/LightningFlowComponents/assets/144791069/1c92966e-300c-4e5c-9cb7-3726cba50719%22%3E)
If you try once more to do the same steps or even delete/add a digit, it works without problem.

Screenshots

the relevant component is LookupFSC
The initiation screen -->
image](https://github.com/alexed1/LightningFlowComponents/assets/144791069/eb795dc2-969f-4b54-870c-733d163c2b71%22%3E)

Can you help determine the cause of this problem? We believe it's because of all the data (>150.000 records) it queries combined with a large amount of sharing rules. Can you confirm this might be the case and what potential solutions are relevant to increase the performance of the component?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant