Changing a rule input variable in a child interface changes it in the parent but SAIL in local variable doesn't?

Sorry, but I do not understand what you are doing here. Please help me.

Why do you store a UI component into a local?

Instead of updatedictionary(), I suggest to use a!update().

francoh7128 said:

using a expression rule does permanently

"does" or "doesn't"?  It sounds like you meant to say "doesn't" but it's a little ambiguous.

If you declare interface components in a local variable, strange things can and will happen sometimes.  You CAN (usually) get it to work, however, but I believe the code in the local variable must be manually declared using a Refresh Variable set to "REFRESH ALWAYS" behavior.

local!sailInterfaceDropdown: a!refreshVariable(
  value: a!sideBySideLayout(
    item: rule!nestedDropdownfield(
      choiceLabels: local!listOfYesNo
      choiceValues: local!listOfYesNo
      value: index(
        local!madeFromCDT,
        "arbitraryField"
        saveInto: a!save(
          local!madeFromCDT,
          updatedictionary(
            dictionary: local!madeFromCDT,
            fieldsAndValues: {arbitraryField: save!value}
          )
        )
      )
    )
  ),
  refreshAlways: true()
)

Additionally, since this manually references the earlier local variable, it's not clear what would happen if, for instance, you then try to reference this local variable multiple times within an interface.  It might just break, or do something even more unexpected.  Generally I avoid doing this except for when I have static UI elements I want to use several times on a form without having to manually declare them everywhere, but even then they only reference generic external variables (like simply saving a single value into a single rule input, like a submit button or similar).

Oh, I'm just trying to figure out more about the variable storage process (what order variables are stored and initialized etc).  I couldn't find that info in the documentation, but it exists for other functionalities.  But yeah, I realize that storing a UI component in a rule expression is best, but I wasn't sure why storing the UI component into a local wouldn't work too.  

I'll use a!update() for the other part though.  

"Does," as in changing a rule input variable in the child successfully changes it in its parent.

But yeah, that does makes sense.  I was trying to tinker with the refresh variable args, but then I realized that using local variables to do it wouldn't be the right way to do it even if it did save a bit of space and a few lines of code.  It made for an interesting learning experience though.  Thank you for your help!

Some references:

https://appian.rocks/2022/07/05/data-in-interfaces/

https://docs.appian.com/suite/help/24.4/SAIL_Performance.html

Thank you!