Summary

Parameter Contexts let you define configuration values once and reuse them across processors, controller services, and process groups. Scoping determines which process groups can use which parameters. This guide explains how parameter contexts work, how inheritance really functions, and what to watch for when assigning them.

1. What a Parameter Context Is

A Parameter Context is a named collection of parameters.

A parameter is a key-value pair used in processor properties:

#{api_url}
#{token}
#{file_path}

Parameters are configuration, not data.
Attributes change per FlowFile; parameters do not.

2. How to Assign a Parameter Context to a Process Group

There are two ways:

A. When creating a new process group

The “Parameter Context” dropdown appears in the dialog.
It defaults to the parent’s parameter context, but you can choose any context.

B. After creation

• Right-click an empty area inside the process group

• Select Configure

• Choose the Parameter Context in the dropdown

A process group may only use one parameter context at a time.

3. How Parameter Scoping Works

Parameter scoping is simple:

• A process group uses the parameter context assigned to it

• Child groups inherit that context unless they explicitly assign another one

• Parameters do not merge across contexts

• If you switch a group’s context, every processor inside now references the new context’s values

This is different from controller service inheritance.
Controller services follow a top-down tree.
Parameter contexts do not.

4. Parameter Context Inheritance (the real kind)

Parameter contexts themselves can inherit from other parameter contexts.

This is done inside the Parameter Context editor:

• Open the hamburger menu → Parameter Contexts

• Edit a context

• Go to the Inheritance tab

• Select the parent context(s)

What this does:

• The child context sees all parameters defined in the parent

• The child can override specific parameter names if needed

• Everything remains clean and explicit

This is not tied to process group hierarchy.
You can build context inheritance in any structure you want.

5. Sensitive Parameters

Parameters can be marked Sensitive.

Behavior:

• Values are hidden in the UI

• They are protected in logs and API responses

• They are only available to processors that explicitly declare support for sensitive parameters

Important note:

A processor may require a parameter to be sensitive or non-sensitive for a given property.
If the parameter type doesn’t match what the processor is expecting, the parameter will not be considered valid.

This is a common point of confusion.

6. When to Use Parameters vs Attributes

Use parameters when the value:

• Is environment-specific (dev/test/prod)

• Should be reused across processors

• Should not vary per FlowFile

• Is sensitive (passwords, tokens)

• Should be managed centrally

Use attributes when the value:

• Comes from data

• Changes per FlowFile

• Drives routing or branching logic

Parameters = environment configuration.
Attributes = data flags.

7. Common Mistakes and Clarifications

Mistake 1: Expecting process groups to inherit and merge contexts

A process group uses exactly one context. No merging.

Mistake 2: Using attributes for configuration

Hard to maintain, error-prone in multi-environment setups.

Mistake 3: Sensitive mismatch

If a processor expects a sensitive parameter but you created a non-sensitive one, it won’t show up.

Mistake 4: Forgetting to reassign context after copying a process group

The copied group may still point to the wrong context.

Mistake 5: Thinking parameter context inheritance has anything to do with process group hierarchy

They are completely independent systems.

Related Articles

• Process Groups and Scoping Overview

• Execution Engine, Concurrency, and Outbound Policy

• Controller Service Inheritance