Hi everyone,
I’m developing a custom app using the IML-based Custom Apps SDK and I’m facing an issue with dependent parameters.
Module structure
I have the following parameter hierarchy:
Object Type (select)
↓
Dynamic Attributes (Yes/No)
↓
Attributes (multiple select, loaded via RPC)
Expected behavior
When the parent parameter (objectTypeId) changes, I would like the dependent attributes field to:
clear its current value
reload the available options
behave similarly to native Make modules (for example Google Sheets, where changing the Spreadsheet clears the Worksheet and Columns automatically)
What is the problem & what have you tried?
Question
Is there any supported way in the public IML SDK to:
clear a dependent parameter when a parent parameter changes?
invalidate the cached value of a multiple select?
recreate or refresh the parameter so previous selections are removed?
Or is this currently a limitation of custom apps?
Screenshots (scenario flow, module settings, errors)
I would not keep these as three top-level sibling parameters. The public Custom Apps SDK documents nested RPC parameters as the supported dependency model; I do not see a documented onChange, clear-value, or cache-invalidation hook for mutating a separate sibling field.
Put dynamicAttributes inside objectTypeId.options.nested, and put the attributes multi-select inside the Yes option’s nested array. The object-type select needs options.store rather than only an RPC string; Make notes that nested RPCs do not work without store. The attributes RPC can then read the inherited parent as {{parameters.objectTypeId}}. The supported pattern is here: Dynamic options RPC | Custom Apps Documentation | Make Developer Hub.
That makes Make regenerate the dependent control in the same hierarchy native modules use. Test by selecting object A, choosing attributes, then switching to a non-overlapping object B and reopening the module. If the old array still survives after true nesting, reduce it to that two-object test and report it as an SDK UI defect; an RPC can change available options, but it should not be treated as an undocumented value-mutation API.
This matches what I’ve run into with nested RPC
parameters too — TinyOpsStudio’s point about the
options.store requirement is the key detail most
people miss when they first try nested dependencies,
since the documentation doesn’t make that requirement
obvious until you hit exactly this bug.
The distinction between “RPC changes available
options” versus “RPC mutates an existing value” is
a good way to frame it for anyone else who searches
this later — it’s not really a limitation, it’s a
different pattern than most people expect coming
from native modules.
