Summary

Processor properties control how a processor behaves. Most new users treat properties as static text, but Clockspring is designed for dynamic values that change based on attributes, parameters, and external data.

Knowing how to use properties well dramatically reduces processor count, simplifies flows, and makes logic reusable.

1. Use Attributes to Drive Dynamic Behavior

Attributes are metadata stored on the FlowFile. You can reference them in many processor properties using expression language:

${attributeName}

This allows processors to behave differently for each FlowFile without branching the flow.

Examples

Dynamic SQL table name in PutDatabaseRecord:

${tableName}

Dynamic API endpoint in InvokeHTTP:

#{base_url}/api/customers/${customer_id}

Dynamic filenames in PutFile:

${filename}.${extension}

Instead of creating 5 processors for 5 endpoints, you create one processor and let attributes decide the destination.

2. Combine Parameters and Attributes (Most Underused Feature)

Parameters handle deployment-time config.
Attributes handle FlowFile-specific values.

You can mix both:

#{api_root}/v1/${resourceType}/${resourceId}

Where:

• #{api_root} → parameter managed at the system level

• ${resourceType} → attribute from the FlowFile

• ${resourceId} → attribute from the FlowFile 

• 
  

This lets you build highly flexible integrations without rewriting properties every time.

3. Understand Sensitive vs Non-Sensitive Property Rules

A processor property is marked as sensitive if it contains credentials or secrets.

This affects parameter usage:

If a parameter isn’t appearing in the dropdown, this mismatch is the reason 95% of the time.

4. Use Expression Language to Reduce Processor Count

Great flows use fewer processors because properties do most of the work.

Instead of:

• RouteOnAttribute → ExtractText → UpdateAttribute → InvokeHTTP
  You can often do it in one or two processors:

• Extract everything into attributes

• Build the endpoint, auth header, or file path dynamically

• Use one InvokeHTTP/PutFile/etc.

Dynamic property evaluation means:

• No copy/paste flows

• No “one processor per endpoint”

• No unnecessary branching

Repeated processor copies are a red flag. Well-designed flows push variation into attributes and parameters, allowing one processor to handle all cases without duplication.

5. Expression Language Evaluation Timing

Clockspring evaluates expressions at specific times:

• Before the processor runs for most properties

• During the session for some content-related functions

• Once per FlowFile, not once per batch

The important takeaway:
Attribute updates in an upstream processor always reflect in the next processor’s properties.

6. Build Reusable Logic Using Attributes

If you rely on properties effectively, you can design processors that work for any:

• table

• endpoint

• file path

• tenant

• message type

• request body

You only update attributes upstream, not processor configs.

Example: One PutDatabaseRecord processor handling 20 tables
Set ${table} upstream.
Done.

Example: One InvokeHTTP handling multiple external systems
Set ${base_url}, ${auth_token}, ${payload} upstream.
Done.

This is how enterprise-grade flows stay maintainable.

7. Avoid Hardcoding Anything

If something might change:

• API URLs

• database names

• root file paths

• credentials

• tenant identifiers

• content types

• query parameters

Put them in parameters or attributes.
Hardcoding creates brittle flows.

Related Articles

• What Is a Processor?

• Using Attributes in Flow Design

• Using Parameters in Clockspring

• FlowFile Content vs Attributes

• Relationships and Routing Basics

• Controller Services Overview