Dropdown choiceValues and values

Certified Associate Developer

How to effectively prevent UI evaluation errors when choiceValues change? 

In my project, we are commonly using a table holding reference data to be displayed in dropdown fields.

The problem is, whenever these values change, the dropdowns get updated, but if a value has been removed or edited, but previously saved to the database, now we get a UI evaluation error saying that the value is not present in the choiceValues - which is understandable, of course.

But how can we effectively guard against this sort of behavior? After an update like this, we usually face a billion errors when users (or developers) bring up an old record or old task, which had a value saved that is no longer present in a dropdown. Is there a good preventive measure for this sort of cases?

  Discussion posts and replies are publicly visible

  • I would suggest curing this problem in a proper way where you just store the ID and not text (label) of the value in the DB. Now it doesn't matter how many times you change the value (label) because the ID remains the same and hence dropdowns will always display the newest value. 

    Now a way to fix it with the text data is to check if the data is present in the choiceValues and if yes, then only show it in the value else show null. 

    That way, whenever a value changes, you will a blank dropdown. 

  • 0
    Certified Associate Developer
    in reply to Harshit Bumb (Appyzie)

    Indeed, this would be a proper way of fixing this problem, though for an old project it seems a bit invasive.

    "Now a way to fix it with the text data is to check if the data is present in the choiceValues and if yes, then only show it in the value else show null."

    I guess this would be a way to prevent the evaluation error, but I think it would be up for debate to decide whether a blank dropdown is even worse than evaluation errors, since they are easier to miss, and errors usually force quick fixes. Am I reasoning correcly?

  • But I can't think of a third way that solves our problem. There is a lengthy way, which includes updating the values in the DB everytime you change the lookup values. 

  • 0
    Certified Lead Developer
    in reply to Harshit Bumb (Appyzie)

    That's actually the approach I would take.  If a value gets removed, you should create a script that cycles through all tables that could reference that value and for each of them replace the removed value with something else. 

    If you don't clean your data right away it stays dirty.  If you and all your colleagues leave the project one day, the poor souls who inherited it will never know what those extraneous values were ever supposed to mean, and they won't be able to fix the lavaflow code after you.  You'll never get approval to clean it after you've done this in a separate story, so you have to while you're doing it.

    The secret to tech debt is to try borrowing as little as possible.  You have to pay it back or pay tons of interest.

    1. Never remove values from the database. Use a Boolean flag (typically labelled 'isActive') to indicate whether the value is currently available for use
    2. Always store the key to the value, not the value itself. Keys are immutable and, if you follow the previous guidance, always available
    3. For new Cases you can exclude those values in the Ref Data that have 'isActive' marked as 'false'. Cases that previously used that value can have that value (and its key) appended to the currently active list to prevent UI failures.
    4. Have very clear rules that determine if a Case that has a value that has an inactive value selected and is now being edited can continue to use that value or that it needs to be replaced with a currently active value. This will be driven by the business requirements. 
  • 0
    Certified Lead Developer
    in reply to Stewart Burchell

    Good stuff, and good to spell out more explicitly.

  • "Now a way to fix it with the text data is to check if the data is present in the choiceValues and if yes, then only show it in the value else show null."

    I guess this would be a way to prevent the evaluation error, but I think it would be up for debate to decide whether a blank dropdown is even worse than evaluation errors, since they are easier to miss, and errors usually force quick fixes. Am I reasoning correcly?

    I'm with Harshit, I almost always configure my dropdowns to check if a value is present in the options, if not, show null.  I can't think of any case where it would be better to have an evaluation error rather than a blank dropdown selection - with a required flag, the user will be forced to choose a new value during submit/resubmit. 

    a!localVariables(
      local!options: { "A", "B", "C" },
      local!selection: "D",
      a!dropdownField(
        label: "Options",
        placeholder: "--Select--",
        choiceLabels: local!options,
        choiceValues: local!options,
        value: if(
          contains(local!options, local!selection),
          local!selection,
          null
        ),
        saveInto: local!selection,
        required: true
      )
    )

  • 0
    Certified Lead Developer
    in reply to Chris

    Somewhat agree all pink = bad.

    However, I would avoid a band-aid that prevents the underlying problem from getting solved.

    However, blank spaces on a dropdown are such glaringly obvious bugs I could scarcely imagine a scenario where fixing it wouldn't be top priority for business, so band-aid would never keep it from getting fixed.