What are sibling parameters and how to use them?

Questions
1

Hello,

While studying Notion’s node I found an interesting syntax:

I failed to find any documentation for it but after looking at n8n’s code I understood that it’s a special syntax for selecting sibling parameteres n8n/packages/workflow/src/workflow-data-proxy.ts at a56d6ab94627902441f86046c60756c464589764 · n8n-io/n8n · GitHub

However it doesn’t seem I can use it for visible items in collection, right?
I right something like this for my fixed collection options and it doesn’t seem to resolve ‘default’ for Field value:

{
						displayName: 'Field Name or ID',
						name: 'key',
						type: 'options',
						description:
							'Choose from the list, or specify an ID using an <a href="https://docs.n8n.io/code/expressions/">expression</a>',
						typeOptions: {
							loadOptionsMethod: 'getWritableFields',
							loadOptionsDependsOn: ['database'],
						},
						default: '',
					},
					{
						displayName: 'Field Type',
						name: 'type',
						type: 'hidden',
						default: '={{$parameter["&key"].parseJson().type}}',
					},
					{
						displayName: 'Field Default Value',
						name: 'defaultValue',
						type: 'hidden',
						default: '={{$parameter["&key"].parseJson().defaultValue}}',
					},
					{
						displayName: 'Field Value',
						name: 'value',
						type: 'string',
						displayOptions: {
							show: {
								type: ['text'],
							},
						},
						default: '={{ $parameter["&defaultValue"] }}',
},

image
image956×1392 95.2 KB

Also I’d like to use it inside displayName but that also doesn’t seem to resolve

Are there any source where I can learn more about it? Thanks in advance for any tips

2

Interesting find, maybe someone from the team can shed some light. I dug a little with AI and although it failed to find any sources that document this, it performed this analysis on the Notion’s node code:

The & parameter reference syntax in n8n is used for accessing sibling parameters within the same node configuration. This is an undocumented internal feature that allows referencing other parameters within the same parameter set.[^1]

Syntax and Functionality

The &key syntax works by accessing sibling parameters where:

  • $parameter["&key"] references another parameter named key in the same parameter group
  • It uses n8n’s workflow data proxy for parameter resolution[^1]
  • This mechanism is implemented in packages/workflow/src/workflow-data-proxy.ts[^1]

Limitations

The syntax has specific restrictions:

Hidden vs Visible Parameters: The & reference syntax only works reliably for hidden type parameters. It does not resolve properly for visible UI elements like string inputs or options dropdowns.[^1]

Collection Item Context: The syntax cannot access neighboring values within fixedCollection items with multiple entries. Each collection item operates in its own parameter scope.[^2]

Default Value Resolution: When used in visible parameters (like type: 'string'), the expression appears as literal text instead of resolving to the actual value.[^1]

Working Example

{
  displayName: 'Property',
  name: 'key',
  type: 'options',
  typeOptions: {
    loadOptionsMethod: 'getDatabaseProperties',
    loadOptionsDependsOn: ['databaseId'],
  },
  default: '',
},
{
  displayName: 'Type',
  name: 'type',
  type: 'hidden',  // Must be hidden
  default: '={{$parameter["&key"].split("|")[^1]}}',  // Works
}

Non-Working Example

{
  displayName: 'Field Value',
  name: 'value',
  type: 'string',  // Visible parameter
  default: '={{ $parameter["&defaultValue"] }}',  // Does not resolve
}

The literal text {{ $parameter["&defaultValue"] }} appears in the UI instead of the resolved value.[^1]

Alternative Solutions

For accessing dynamic values in visible parameters:

  • Use loadOptionsMethod with loadOptionsDependsOn for dynamic option loading[^3][^2]
  • Implement parameter resolution in the node’s execution logic rather than parameter defaults
  • Use separate hidden parameters to store computed values, then reference them in execution code

This syntax remains undocumented and is primarily used internally by n8n’s core nodes. Its usage in custom nodes should be limited to hidden parameters for reliable functionality.[^1]

<div style="text-align: center">⁂</div>
3

that’s an interesting idea. Are you aware of any examples where it’s done?

4

I myself no, but used AI to search for me, hope this helps:

parameter resolution in the node’s execution logic examples

Parameter resolution in the node’s execution logic is commonly used in n8n core nodes instead of relying on parameter defaults. Here are concrete examples from n8n’s source code:

HTTP Request Node Example

The HTTP Request node extensively resolves parameters during execution rather than using defaults . In HttpRequestV3.node.ts, parameters are processed within the execute() method:

async execute(this: IExecuteFunctions): Promise<INodeExecutionData[][]> {
  const items = this.getInputData();
  
  for (let itemIndex = 0; itemIndex < items.length; itemIndex++) {
    // Dynamic parameter resolution during execution
    const requestMethod = this.getNodeParameter('method', itemIndex) as IHttpRequestMethods;
    const sendQuery = this.getNodeParameter('sendQuery', itemIndex, false) as boolean;
    const queryParameters = this.getNodeParameter('queryParameters.parameters', itemIndex, []);
    const bodyContentType = this.getNodeParameter('contentType', itemIndex, '') as string;
    
    // Conditional parameter processing based on other parameters
    if (sendQuery && queryParameters) {
      if (specifyQuery === 'keypair') {
        requestOptions.qs = await reduceAsync(queryParameters, parametersToKeyValue);
      } else if (specifyQuery === 'json') {
        requestOptions.qs = jsonParse(jsonQueryParameter);
      }
    }
  }
}

Dynamic Parameter Dependencies

The search results show nodes using loadOptionsDependsOn for dynamic parameter loading :[^1][^2]

// In parameter description
typeOptions: {
  loadOptionsMethod: 'getDatabaseProperties',
  loadOptionsDependsOn: ['databaseId'],
}

// In execute method - process the resolved options
const selectedProperty = this.getNodeParameter('property', itemIndex) as string;
const propertyType = this.getNodeParameter('type', itemIndex) as string;

// Use these resolved values to build the actual request
const processedValue = processPropertyBasedOnType(selectedProperty, propertyType);

Conditional Parameter Processing

From the community discussions , nodes frequently implement conditional logic in the execute method:[^3][^4]

async execute(this: IExecuteFunctions): Promise<INodeExecutionData[][]> {
  const operation = this.getNodeParameter('operation', 0) as string;
  const resource = this.getNodeParameter('resource', 0) as string;
  
  // Resolve parameters based on operation/resource combination
  if (resource === 'database' && operation === 'create') {
    const databaseId = this.getNodeParameter('databaseId', itemIndex) as string;
    const properties = this.getNodeParameter('properties', itemIndex) as IDataObject[];
    
    // Process each property based on its type (resolved dynamically)
    const processedProperties = {};
    for (const prop of properties) {
      const fieldType = await this.getFieldType(prop.key);
      processedProperties[prop.key] = this.formatValueForType(prop.value, fieldType);
    }
  }
}

Parameter Validation and Transformation

Nodes commonly validate and transform parameters during execution :[^5][^6]

// Parameter resolution with validation
const jsonBodyParameter = this.getNodeParameter('jsonBody', itemIndex, '') as string;

if (typeof jsonBodyParameter !== 'object' && jsonBodyParameter !== null) {
  try {
    JSON.parse(jsonBodyParameter);
  } catch {
    throw new NodeOperationError(this.getNode(), 'JSON parameter needs to be valid JSON');
  }
  requestOptions.body = jsonParse(jsonBodyParameter);
}

This approach provides several advantages over parameter defaults:

  • Runtime validation: Parameters can be validated against current context
  • Cross-parameter dependencies: One parameter’s value can influence how others are processed
  • Dynamic type conversion: Values can be transformed based on other parameter selections
  • Error handling: Specific error messages can be provided for invalid combinations

The execution-time approach is particularly useful when parameter values need to be computed based on API responses, user selections, or complex business logic that cannot be expressed in static parameter defaults.[^7][^4]

<div style="text-align: center">⁂</div>e hidden
5

ah, no. That’s not what I was looking for.
For a second I thought there is a way to programatically build a list of UI parameteres which I can show to user

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.