Boomi Process Property Components: The Complete Guide with Real-World Examples

If you’ve ever hardcoded connection details, API endpoints, or configuration values directly into your Boomi processes, you’ve probably felt the pain when those values need to change. Or worse—when you need to deploy the same process to different environments with different settings.

That’s where Process Property Components become your best friend.

In this comprehensive guide, I’ll show you everything you need to know about Process Property Components: what they are, when to use them, how they differ from Dynamic Process Properties, and most importantly—real-world examples that will make your integrations more maintainable, scalable, and environment-aware.

What Are Process Property Components?
Process Property Components vs Dynamic Process Properties
Creating Your First Process Property Component
Data Types and Configuration Options
Real-World Use Cases
Working with Extensions for Environment-Specific Values
Process Property Components in Groovy Scripts
Best Practices and Design Patterns
Common Pitfalls and How to Avoid Them
When NOT to Use Process Property Components

What Are Process Property Components?

Process Property Components are reusable configuration containers that store collections of name-value pairs. Think of them as configuration files for your integrations—centralized, organized, and easy to maintain.

Unlike Dynamic Process Properties (which are created on-the-fly during execution), Process Property Components are:

Pre-defined: Created in your Process Library before use
Reusable: One component can be used across multiple processes
Strongly-typed: Support multiple data types (String, Number, Date, Boolean, Hidden)
Visible: Easy to find and manage in Component Explorer
Extensible: Values can be overridden per environment without changing the process

Key Advantages:

Centralized configuration management
No need to remember property names (like with DPPs)
Type safety prevents data conversion errors
Environment-specific value overrides
Better organization and documentation
Visible in Component Explorer and Choose Property dialogs

Process Property Components vs Dynamic Process Properties

Let’s settle this once and for all—when should you use each?

Aspect	Process Property Components	Dynamic Process Properties
Creation	Pre-defined in Process Library	Created on-the-fly in Set Properties shape
Visibility	Listed in Component Explorer	Must remember exact names
Data Types	Boolean, Date, Hidden, Number, String	String only (requires manual conversion)
Reusability	Used across multiple processes	Typically single-process
Environment Extensions	Full support with UI	Limited support
Maintenance	Easy to update centrally	Must find and update in each process
Documentation	Help text and labels built-in	No built-in documentation
Best For	Configuration settings, credentials, URLs	Runtime temporary values, counters
Boomi Recommendation	Use these for new projects	Legacy support, quick prototypes

Boomi’s Official Stance: “If you have never used dynamic process properties, you should use process property components instead. Process property components are more powerful and easier to work with.”

When to Choose Each:

Use Process Property Components when:

The value is used in multiple processes
The value changes between environments (Dev/Test/Prod)
You need type safety (numbers, dates, booleans)
You want non-technical users to update values via extensions
You’re building for long-term maintainability

Use Dynamic Process Properties when:

You need a quick temporary variable during execution
The value is calculated dynamically
You’re tracking state within a single execution
Speed of development matters more than maintainability

Creating Your First Process Property Component

Let’s walk through creating a Process Property Component step-by-step.

Step 1: Navigate to Process Library

From the Boomi interface:

Go to Manage → Process Library
Click Create New → Process Property

Or from Build page:

Click the + Create New button
Select Process Property from the dropdown

Step 2: Name Your Component

Component Name: Environment_Configuration
Folder: /Configuration/Process Properties

Naming Convention Best Practice:

Use descriptive, clear names
Group related properties in one component
Examples:
- Salesforce_Connection_Config
- Email_Notification_Settings
- API_Rate_Limit_Config

Step 3: Add Properties

Click Add Property and configure each property:

Example: API Configuration

Property 1:

Label: API Base URL
Key: api_base_url (auto-generated)
Data Type: String
Default Value: https://api.example.com/v1
Help Text: Base URL for API calls. Override in environment extensions for different environments.
Persist: No (typically)

Property 2:

Label: API Timeout (seconds)
Key: api_timeout
Data Type: Number
Default Value: 30
Help Text: Timeout in seconds for API requests
Allowed Values: 10, 30, 60, 120

Property 3:

Label: Enable Debug Logging
Key: debug_logging
Data Type: Boolean
Default Value: False (unchecked)
Help Text: Enable verbose logging for troubleshooting

Property 4:

Label: API Key
Key: api_key
Data Type: Hidden
Default Value: (leave blank for security)
Help Text: API authentication key. Set via environment extensions.

Step 4: Save and Use

After saving, your component appears in:

Component Explorer → Process Properties category
Choose Property dialogs throughout Boomi
Set Properties shapes

Data Types and Configuration Options

Understanding data types is crucial for effective use of Process Property Components.

Available Data Types

1. String

Use for: Text values, URLs, file paths, IDs

Example:

Property: Database Connection String
Data Type: String
Default: jdbc:postgresql://localhost:5432/mydb
Allowed Values: (optional - restrict to specific values)

Allowed Values Feature:

Value: jdbc:postgresql://prod-db:5432/proddb | Label: Production
Value: jdbc:postgresql://test-db:5432/testdb | Label: Test
Value: jdbc:postgresql://dev-db:5432/devdb  | Label: Development

2. Number

Use for: Counts, timeouts, port numbers, thresholds

Example:

Property: Batch Size
Data Type: Number
Default: 100
Allowed Values: 
  - 50 (Small batches)
  - 100 (Standard)
  - 500 (Large batches)
  - 1000 (Maximum)

Important: Numbers are stored as integers or decimals but retrieved as strings in some contexts.

3. Boolean

Use for: Feature flags, enable/disable switches

Example:

Property: Send Email Notifications
Data Type: Boolean
Default: True (checked)
Help Text: Enable/disable email notifications for process completion

Usage in Decisions:

If: {1:Email_Config.send_notifications} = true
Then: Send_Email_Branch
Else: Skip_Branch

4. Date

Use for: Cutoff dates, start dates, timestamps

Example:

Property: Data Load Start Date
Data Type: Date
Default: 2025-01-01
Help Text: Beginning date for historical data loading

Format: Typically YYYY-MM-DD, but verify in your context

5. Hidden

Use for: Sensitive data that shouldn’t be visible in UI (but NOT passwords!)

Example:

Property: Internal System ID
Data Type: Hidden
Default: INTERNAL_SYS_12345
Help Text: System identifier for internal use only

⚠️ Critical Warning: Hidden properties are NOT encrypted. Do NOT use for passwords or sensitive credentials. Use connection components with proper authentication instead.

Configuration Options

Persistence

☑ Persist this property

What it does: Stores the value across process executions

When to enable:

Configuration values that rarely change
Default settings for new deployments
Non-sensitive reference data

When to disable:

Values that should reset each execution
Environment-specific values (use extensions instead)

Help Text

Help Text: This URL is used for all API calls to the external system. 
           Override in each environment using Environment Extensions.

Best Practices:

Explain what the property controls
Mention if it should be overridden per environment
Include format requirements or examples
Document dependencies on other properties

Allowed Values

Allowed Values:
  Value: INFO  | Label: Information Level
  Value: DEBUG | Label: Debug Level
  Value: ERROR | Label: Error Level Only

Benefits:

Prevents typos and invalid values
Creates dropdown in Environment Extensions UI
Self-documenting valid options
Easier for non-technical users

Real-World Use Cases

Let’s explore practical scenarios where Process Property Components excel.

Use Case 1: Multi-Environment API Configuration

Scenario: You have a process that calls an external API, but the API endpoints, credentials, and behavior differ between Dev, Test, and Production environments.

Solution: Create a Process Property Component with environment-specific settings.

Component: API_External_Config

Properties:
1. Label: API Base URL
   Key: base_url
   Type: String
   Default: https://api-dev.example.com
   Help: API endpoint base URL

2. Label: API Version
   Key: api_version
   Type: String
   Default: v2
   Allowed Values: v1, v2, v3

3. Label: Rate Limit (requests/minute)
   Key: rate_limit
   Type: Number
   Default: 60
   Help: Maximum API calls per minute

4. Label: Enable Retry Logic
   Key: enable_retry
   Type: Boolean
   Default: true

5. Label: Max Retry Attempts
   Key: max_retries
   Type: Number
   Default: 3

Using in HTTP Connector

URL Field:

{1:API_External_Config.base_url}/{1:API_External_Config.api_version}/customers

Custom Header (X-Api-Version):

{1:API_External_Config.api_version}

Environment Extension Values

Development Environment:

base_url: https://api-dev.example.com
api_version: v2
rate_limit: 100
enable_retry: true
max_retries: 5

Production Environment:

base_url: https://api.example.com
api_version: v3
rate_limit: 60
enable_retry: true
max_retries: 3

Benefits:

Single process works across all environments
No code changes when deploying
Non-technical staff can update URLs
Clear documentation of environment differences

Use Case 2: Database Connection Configuration

Scenario: Your integration connects to different databases in each environment with different credentials, ports, and schemas.

Solution: Centralized database configuration component.

Component: Database_Connection_Config

Properties:
1. Label: Database Host
   Key: db_host
   Type: String
   Default: localhost

2. Label: Database Port
   Key: db_port
   Type: Number
   Default: 5432

3. Label: Database Name
   Key: db_name
   Type: String
   Default: myapp_dev

4. Label: Schema Name
   Key: schema_name
   Type: String
   Default: public

5. Label: Connection Timeout (seconds)
   Key: connection_timeout
   Type: Number
   Default: 30

6. Label: Query Timeout (seconds)
   Key: query_timeout
   Type: Number
   Default: 60

Using in Database Connector

Connection URL:

jdbc:postgresql://{1:Database_Connection_Config.db_host}:{1:Database_Connection_Config.db_port}/{1:Database_Connection_Config.db_name}

SQL Query:

sql

SELECT * FROM {1:Database_Connection_Config.schema_name}.customers 
WHERE updated_date > CURRENT_DATE - INTERVAL '7 days'

Groovy Script with Connection Config

groovy

import com.boomi.execution.ExecutionUtil;

// Get database configuration
String dbHost = ExecutionUtil.getProcessProperty("component_id", "db_host");
String dbPort = ExecutionUtil.getProcessProperty("component_id", "db_port");
String dbName = ExecutionUtil.getProcessProperty("component_id", "db_name");

// Build connection string
String connectionString = "jdbc:postgresql://" + dbHost + ":" + dbPort + "/" + dbName;

logger.info("Connecting to database: " + connectionString);

// Use in your logic
// ...

Use Case 3: Email Notification Settings

Scenario: Multiple processes send email notifications with similar formatting and recipients, but settings vary by environment and notification type.

Solution: Shared email configuration component.

Component: Email_Notification_Config

Properties:
1. Label: SMTP Server
   Key: smtp_server
   Type: String
   Default: smtp.office365.com

2. Label: SMTP Port
   Key: smtp_port
   Type: Number
   Default: 587

3. Label: From Email Address
   Key: from_email
   Type: String
   Default: integrations@company.com

4. Label: Error Notification Recipients
   Key: error_recipients
   Type: String
   Default: errors@company.com

5. Label: Success Notification Recipients
   Key: success_recipients
   Type: String
   Default: success-team@company.com

6. Label: Send Notifications Enabled
   Key: notifications_enabled
   Type: Boolean
   Default: true

7. Label: Include Detailed Logs
   Key: include_details
   Type: Boolean
   Default: false

Using in Email Connector

SMTP Configuration:

Host: {1:Email_Notification_Config.smtp_server}
Port: {1:Email_Notification_Config.smtp_port}
From: {1:Email_Notification_Config.from_email}

Dynamic Recipient Selection:

In a Decision Shape:

If: {1:current_status} = ERROR
Then: Route to error handling
  - To: {1:Email_Notification_Config.error_recipients}
Else: Route to success handling
  - To: {1:Email_Notification_Config.success_recipients}

Environment Overrides

Development:

smtp_server: smtp-test.company.com
from_email: dev-integrations@company.com
error_recipients: dev-team@company.com
success_recipients: dev-team@company.com
notifications_enabled: false  // Don't spam in dev

Production:

smtp_server: smtp.company.com
from_email: prod-integrations@company.com
error_recipients: errors@company.com, oncall@company.com
success_recipients: success-team@company.com
notifications_enabled: true
include_details: false  // Reduce log exposure

Use Case 4: Feature Flags and Conditional Logic

Scenario: You want to enable/disable features in your integration without redeploying processes.

Solution: Feature flag configuration component.

Component: Feature_Flags

Properties:
1. Label: Enable Advanced Validation
   Key: enable_advanced_validation
   Type: Boolean
   Default: false

2. Label: Use New API Endpoint
   Key: use_new_api
   Type: Boolean
   Default: false

3. Label: Enable Data Caching
   Key: enable_caching
   Type: Boolean
   Default: true

4. Label: Maximum Cache Age (minutes)
   Key: cache_max_age
   Type: Number
   Default: 30

5. Label: Enable Beta Features
   Key: enable_beta
   Type: Boolean
   Default: false

Using Feature Flags in Process Logic

Decision Shape 1: Validation Branch

If: {1:Feature_Flags.enable_advanced_validation} = true
Then: Execute_Advanced_Validation_Subprocess
Else: Execute_Standard_Validation

Decision Shape 2: API Routing

If: {1:Feature_Flags.use_new_api} = true
Then: Call_New_API_v3_Endpoint
Else: Call_Legacy_API_v2_Endpoint

Decision Shape 3: Caching Logic

If: {1:Feature_Flags.enable_caching} = true
Then: Check_Cache_Before_API_Call
Else: Direct_API_Call

Groovy Script for Complex Feature Logic

groovy

import com.boomi.execution.ExecutionUtil;

// Get feature flags
String enableBetaStr = ExecutionUtil.getProcessProperty("Feature_Flags_ComponentID", "enable_beta");
String enableCachingStr = ExecutionUtil.getProcessProperty("Feature_Flags_ComponentID", "enable_caching");
String cacheMaxAgeStr = ExecutionUtil.getProcessProperty("Feature_Flags_ComponentID", "cache_max_age");

// Convert to appropriate types
boolean enableBeta = Boolean.parseBoolean(enableBetaStr);
boolean enableCaching = Boolean.parseBoolean(enableCachingStr);
int cacheMaxAge = Integer.parseInt(cacheMaxAgeStr);

// Complex feature logic
if (enableBeta && enableCaching) {
    logger.info("Beta features enabled with caching - using optimized path");
    // Set dynamic property for later use
    ExecutionUtil.setDynamicProcessProperty("USE_OPTIMIZED_PATH", "true", false);
} else if (enableBeta && !enableCaching) {
    logger.warning("Beta enabled without caching - performance may be impacted");
    ExecutionUtil.setDynamicProcessProperty("USE_OPTIMIZED_PATH", "false", false);
} else {
    logger.info("Standard features - using normal execution path");
    ExecutionUtil.setDynamicProcessProperty("USE_OPTIMIZED_PATH", "false", false);
}

Benefits:

Enable/disable features instantly via extensions
A/B testing in production
Gradual rollout of new functionality
Emergency kill switches
No code deployment required

Use Case 5: File Processing Configuration

Scenario: Your integration processes files from various sources with different naming conventions, paths, and retention policies.

Solution: File processing configuration component.

Component: File_Processing_Config

Properties:
1. Label: Input File Path
   Key: input_path
   Type: String
   Default: /mnt/data/inbound/

2. Label: Output File Path
   Key: output_path
   Type: String
   Default: /mnt/data/outbound/

3. Label: Archive Path
   Key: archive_path
   Type: String
   Default: /mnt/data/archive/

4. Label: File Name Pattern
   Key: file_pattern
   Type: String
   Default: *.csv
   Help: Regex pattern for file selection

5. Label: Archive After Processing
   Key: archive_enabled
   Type: Boolean
   Default: true

6. Label: Archive Retention Days
   Key: archive_retention_days
   Type: Number
   Default: 90

7. Label: Max File Size (MB)
   Key: max_file_size_mb
   Type: Number
   Default: 100

Using in Disk Connector

Read Operation:

Directory: {1:File_Processing_Config.input_path}
File Name Pattern: {1:File_Processing_Config.file_pattern}

Write Operation:

Directory: {1:File_Processing_Config.output_path}
File Name: processed_{1:execution_id}.csv

Groovy Script for File Validation

groovy

import com.boomi.execution.ExecutionUtil;
import java.io.InputStream;
import java.util.Properties;

def maxFileSizeStr = ExecutionUtil.getProcessProperty("File_Processing_Config_ID", "max_file_size_mb");
def maxFileSizeMB = Integer.parseInt(maxFileSizeStr);
def maxFileSizeBytes = maxFileSizeMB * 1024 * 1024;

for (int i = 0; i < dataContext.getDataCount(); i++) {
    InputStream is = dataContext.getStream(i);
    Properties props = dataContext.getProperties(i);
    
    // Get file size
    long fileSize = is.available();
    
    if (fileSize > maxFileSizeBytes) {
        logger.severe("File size " + (fileSize / 1024 / 1024) + "MB exceeds limit of " + maxFileSizeMB + "MB");
        props.setProperty("document.dynamic.userdefined.FILE_TOO_LARGE", "true");
    } else {
        props.setProperty("document.dynamic.userdefined.FILE_TOO_LARGE", "false");
    }
    
    dataContext.storeStream(is, props);
}

Use Case 6: Business Rules and Thresholds

Scenario: Your integration has business logic with configurable thresholds that vary by environment or change seasonally.

Solution: Business rules configuration component.

Component: Business_Rules_Config

Properties:
1. Label: High Priority Order Threshold
   Key: high_priority_threshold
   Type: Number
   Default: 10000
   Help: Order amount in USD to trigger high priority processing

2. Label: Auto-Approve Limit
   Key: auto_approve_limit
   Type: Number
   Default: 5000
   Help: Maximum amount for automatic approval

3. Label: Require Manager Approval
   Key: require_manager_approval
   Type: Boolean
   Default: true

4. Label: Bulk Discount Percentage
   Key: bulk_discount_percent
   Type: Number
   Default: 10
   Allowed Values: 5, 10, 15, 20

5. Label: Minimum Bulk Quantity
   Key: min_bulk_quantity
   Type: Number
   Default: 100

6. Label: Payment Terms (days)
   Key: payment_terms_days
   Type: Number
   Default: 30
   Allowed Values: 15, 30, 45, 60

Using in Business Logic

Decision Shape: Priority Routing

If: {1:order_total} >= {1:Business_Rules_Config.high_priority_threshold}
Then: Route_to_Priority_Queue
Else: Route_to_Standard_Queue

Decision Shape: Approval Workflow

If: {1:order_total} <= {1:Business_Rules_Config.auto_approve_limit}
Then: Auto_Approve
Else If: {1:Business_Rules_Config.require_manager_approval} = true
Then: Route_to_Manager_Approval
Else: Manual_Review

Groovy Script for Discount Calculation

groovy

import com.boomi.execution.ExecutionUtil;
import java.io.InputStream;
import java.util.Properties;

def bulkDiscountStr = ExecutionUtil.getProcessProperty("Business_Rules_Config_ID", "bulk_discount_percent");
def minBulkQtyStr = ExecutionUtil.getProcessProperty("Business_Rules_Config_ID", "min_bulk_quantity");

double bulkDiscountPercent = Double.parseDouble(bulkDiscountStr);
int minBulkQuantity = Integer.parseInt(minBulkQtyStr);

for (int i = 0; i < dataContext.getDataCount(); i++) {
    InputStream is = dataContext.getStream(i);
    Properties props = dataContext.getProperties(i);
    
    // Get order details
    String quantityStr = props.getProperty("document.dynamic.userdefined.ORDER_QUANTITY");
    String priceStr = props.getProperty("document.dynamic.userdefined.UNIT_PRICE");
    
    int quantity = Integer.parseInt(quantityStr);
    double unitPrice = Double.parseDouble(priceStr);
    
    double totalAmount = quantity * unitPrice;
    
    // Apply bulk discount if applicable
    if (quantity >= minBulkQuantity) {
        double discount = totalAmount * (bulkDiscountPercent / 100);
        totalAmount -= discount;
        props.setProperty("document.dynamic.userdefined.DISCOUNT_APPLIED", String.valueOf(discount));
        logger.info("Bulk discount of " + bulkDiscountPercent + "% applied: $" + discount);
    }
    
    props.setProperty("document.dynamic.userdefined.FINAL_AMOUNT", String.valueOf(totalAmount));
    dataContext.storeStream(is, props);
}

Working with Extensions for Environment-Specific Values

Extensions are the killer feature of Process Property Components—they let you override values per environment without changing your process.

What Are Extensions?

Extensions allow you to:

Override component default values at deployment time
Set different values for Dev, Test, and Production
Change configuration without redeploying processes
Provide environment-specific settings to non-technical staff

Setting Up Extensions

Step 1: Define Extensions in Your Process

When you reference a Process Property Component in your process, Boomi automatically creates an extension point.

Example: Add a Set Properties shape using your component:

Set Properties Shape:
  → Choose Property: Environment_Configuration
  → Property: api_base_url

This creates an extension that can be overridden at deployment.

Step 2: Deploy Your Process

Go to Deploy → Deployments
Deploy your process to an environment (e.g., “Production”)

Step 3: Set Environment Extensions

Go to Manage → Runtime Management
Select your environment (e.g., “Production”)
Click Environment Extensions
Select Process Properties tab
Find your Process Property Component
Clear Use Default? checkbox for properties you want to override
Enter environment-specific values
Click OK

Environment Extension Example

Component Default Values (set in Process Library):

API_External_Config:
  base_url: https://api-dev.example.com
  rate_limit: 100
  enable_retry: true

Development Environment Extensions:

API_External_Config:
  base_url: https://api-dev.example.com (default)
  rate_limit: 200 (override - higher limit for testing)
  enable_retry: true (default)

Production Environment Extensions:

API_External_Config:
  base_url: https://api.example.com (override - prod URL)
  rate_limit: 60 (override - respect prod limits)
  enable_retry: true (default)

Extension Best Practices

1. Use Defaults Wisely:

Set defaults to the most common value (usually Dev)
Document which values MUST be overridden in production

2. Clear Documentation:

Use Help Text to explain what should be overridden per environment
Document dependencies between properties

3. Naming Conventions:

Property Label: Database Host (MUST OVERRIDE IN PROD)
Help Text: Database hostname. PRODUCTION: use db-prod.company.com

4. Environment Checklist:

Create a deployment checklist for each environment:

markdown

## Production Deployment Checklist

Process Property Extensions to Verify:
- [ ] API_Config.base_url = https://api.company.com
- [ ] Database_Config.host = db-prod.company.com
- [ ] Email_Config.from_email = production@company.com
- [ ] Email_Config.error_recipients = oncall@company.com
- [ ] Feature_Flags.enable_beta = false

Process Property Components in Groovy Scripts

Accessing Process Property Components programmatically gives you maximum flexibility.

Import Required Class

groovy

import com.boomi.execution.ExecutionUtil;

Retrieving Process Property Values

Basic Syntax:

groovy

String value = ExecutionUtil.getProcessProperty("ComponentID", "PropertyKey");

How to Find Component ID and Property Key:

Open your Process Property Component
The Component ID is visible in the component URL or Revision History
Each property has a Key field showing the property key

Example:

groovy

import com.boomi.execution.ExecutionUtil;

// Component ID: abc123def456
// Property Key: api_base_url

String apiUrl = ExecutionUtil.getProcessProperty("abc123def456", "api_base_url");
logger.info("Using API URL: " + apiUrl);

Setting Process Property Values

Syntax:

groovy

ExecutionUtil.setProcessProperty("ComponentID", "PropertyKey", "NewValue");

Example:

groovy

import com.boomi.execution.ExecutionUtil;

// Update a property value during execution
String newTimeout = "60";
ExecutionUtil.setProcessProperty("abc123def456", "api_timeout", newTimeout);

logger.info("API timeout updated to: " + newTimeout + " seconds");

⚠️ Important: Setting a property value changes it for the current execution only. The change doesn’t persist to the component or affect other executions.

Type Conversion

Process Properties are retrieved as Strings, so you need to convert them:

String to Integer:

groovy

String timeoutStr = ExecutionUtil.getProcessProperty("ComponentID", "timeout");
int timeout = Integer.parseInt(timeoutStr);

String to Double:

groovy

String rateStr = ExecutionUtil.getProcessProperty("ComponentID", "rate_limit");
double rateLimit = Double.parseDouble(rateStr);

String to Boolean:

groovy

String enabledStr = ExecutionUtil.getProcessProperty("ComponentID", "feature_enabled");
boolean isEnabled = Boolean.parseBoolean(enabledStr);

String to Date:

groovy

import java.text.SimpleDateFormat;
import java.util.Date;

String dateStr = ExecutionUtil.getProcessProperty("ComponentID", "start_date");
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
Date startDate = sdf.parse(dateStr);

Complete Example: Dynamic Configuration Loading

groovy

import com.boomi.execution.ExecutionUtil;
import java.util.logging.Logger;

Logger logger = Logger.getLogger("ConfigLoader");

// Component ID (find this in your component)
String componentId = "abc123def456";

// Load all configuration
String apiUrl = ExecutionUtil.getProcessProperty(componentId, "api_base_url");
String apiVersion = ExecutionUtil.getProcessProperty(componentId, "api_version");
String timeoutStr = ExecutionUtil.getProcessProperty(componentId, "api_timeout");
String enableRetryStr = ExecutionUtil.getProcessProperty(componentId, "enable_retry");
String maxRetriesStr = ExecutionUtil.getProcessProperty(componentId, "max_retries");

// Convert types
int timeout = Integer.parseInt(timeoutStr);
boolean enableRetry = Boolean.parseBoolean(enableRetryStr);
int maxRetries = Integer.parseInt(maxRetriesStr);

// Build full API endpoint
String fullEndpoint = apiUrl + "/" + apiVersion + "/customers";

// Log configuration
logger.info("=== API Configuration Loaded ===");
logger.info("Endpoint: " + fullEndpoint);
logger.info("Timeout: " + timeout + " seconds");
logger.info("Retry Enabled: " + enableRetry);
if (enableRetry) {
    logger.info("Max Retries: " + maxRetries);
}

// Store for use in process
ExecutionUtil.setDynamicProcessProperty("FULL_API_ENDPOINT", fullEndpoint, false);
ExecutionUtil.setDynamicProcessProperty("API_TIMEOUT", timeoutStr, false);

Handling Missing or Null Values

groovy

import com.boomi.execution.ExecutionUtil;

String componentId = "abc123def456";
String propertyKey = "optional_setting";

try {
    String value = ExecutionUtil.getProcessProperty(componentId, propertyKey);
    
    if (value == null || value.isEmpty()) {
        logger.warning("Property '" + propertyKey + "' is null or empty, using default");
        value = "default_value";
    }
    
    // Use the value
    logger.info("Using value: " + value);
    
} catch (Exception e) {
    logger.severe("Error retrieving property: " + e.getMessage());
    // Use fallback value
    String value = "fallback_value";
}

Best Practices and Design Patterns

1. Organize Properties into Logical Components

❌ Bad: One Giant Component

Global_Config:
  - database_host
  - api_url
  - email_server
  - ftp_host
  - logging_level
  - retry_count
  (50 more properties...)

✅ Good: Multiple Focused Components

Database_Config:
  - host
  - port
  - name
  - schema

API_Config:
  - base_url
  - version
  - timeout

Email_Config:
  - smtp_server
  - from_address
  - recipients

File_Transfer_Config:
  - ftp_host
  - directory
  - protocol

Benefits:

Easier to find properties
Better reusability (one process might need API but not Email)
Clearer ownership and maintenance
Simpler environment extensions

2. Naming Conventions

Component Names:

✅ Good:
  - Salesforce_Connection_Config
  - Email_Notification_Settings
  - API_Rate_Limit_Rules

❌ Bad:
  - Config1
  - Properties
  - Settings

Property Labels:

✅ Good:
  - API Base URL
  - Database Port
  - Enable Debug Logging
  - Maximum Retry Attempts

❌ Bad:
  - url
  - port
  - flag
  - num

Property Keys (auto-generated but customizable):

✅ Good:
  - api_base_url
  - database_port
  - enable_debug
  - max_retries

❌ Bad:
  - prop1
  - value
  - setting

3. Documentation Standards

Always Include Help Text:

Property: API Base URL
Help Text: Base URL for external API calls. 
           Production: https://api.company.com
           Test: https://api-test.company.com
           Dev: https://api-dev.company.com
           Override via Environment Extensions.

Document Dependencies:

Property: Enable Advanced Features
Help Text: Enables advanced processing logic. 
           Requires: max_batch_size >= 100
           Only enable in Production after testing.

Document Constraints:

Property: API Timeout
Help Text: Timeout for API calls in seconds.
           Valid range: 10-300
           Recommended: 30 for most scenarios
           Increase to 60 for large data transfers.

4. Default Value Strategy

Choose Default Values Strategically:

Option A: Use Development as Default

Rationale: Most processes start in Dev
Default: Dev-specific values
Override: Test and Prod via extensions

Example:
  api_base_url: https://api-dev.example.com (default)
  Environment Extensions:
    Test: https://api-test.example.com
    Prod: https://api.example.com

Option B: Use Safe/Conservative as Default

Rationale: Prevent accidental damage
Default: Most restrictive/safest values
Override: All environments via extensions

Example:
  enable_data_deletion: false (default)
  batch_size: 10 (small, safe default)
  Environment Extensions:
    Dev: enable_data_deletion=true, batch_size=1000
    Test: enable_data_deletion=true, batch_size=500
    Prod: enable_data_deletion=false, batch_size=100

5. Use Allowed Values for Controlled Options

Prevent Invalid Values:

Property: Log Level
Data Type: String
Allowed Values:
  - DEBUG | Debug (verbose logging)
  - INFO  | Information (standard logging)
  - WARN  | Warning (warnings and errors)
  - ERROR | Error (errors only)
Default: INFO

Benefits:

Dropdown in Extensions UI
No typos or invalid values
Self-documenting valid options

6. Versioning and Change Management

Track Changes:

Use descriptive component names with version hints when major changes occur
Document breaking changes in Help Text
Maintain changelog in a separate document

Example Changelog:

markdown

# API_Config Changelog

## v2.0 (2025-01-15)
- Added: api_version property
- Changed: Renamed timeout to api_timeout for clarity
- Breaking: Removed deprecated legacy_mode property

## v1.5 (2024-12-01)
- Added: enable_retry and max_retries properties
- Changed: Increased default timeout from 30 to 60 seconds

## v1.0 (2024-11-01)
- Initial release
- Properties: api_base_url, timeout

7. Security Best Practices

❌ NEVER Store Passwords in Process Properties:

Property: Database Password
Data Type: Hidden  ← Still NOT encrypted!
Default: MyPassword123  ← VERY BAD

✅ Use Proper Authentication:

Option 1: Connection Components
  - Use Boomi's built-in connections with encrypted credentials

Option 2: External Secret Management
  - AWS Secrets Manager
  - Azure Key Vault
  - HashiCorp Vault
  - Retrieve secrets at runtime via API

Option 3: Certificate-Based Auth
  - Use certificates instead of passwords

For API Keys and Tokens:

Property: API Key
Data Type: Hidden
Default: (leave blank)
Help Text: Set via Environment Extensions. 
           DO NOT commit to source control.
           Retrieve from AWS Secrets Manager in production.

8. Testing Strategy

Create Test-Specific Component Variants:

Component: API_Config_Test
  - All properties have test-safe defaults
  - No external system dependencies
  - Uses mock endpoints

Component: API_Config_Prod
  - Production-ready defaults
  - Real endpoint configurations
  - Strict validation rules

Or Use Single Component with Clear Test Defaults:

Component: API_Config
  Default values = safe for testing
  Extensions = environment-specific overrides

Common Pitfalls and How to Avoid Them

Pitfall 1: Forgetting to Override Extensions in Production

Problem:

Developer sets default to Dev values
Deploys to Production
Production uses Dev database URL
Data goes to wrong system

Solution:

Create deployment checklist
Use naming that indicates override needed: “API URL (OVERRIDE IN PROD)”
Set defaults to obviously wrong values that will fail safely:

  Default: https://SET_THIS_IN_ENVIRONMENT_EXTENSIONS.example.com

Implement validation in Groovy scripts:

groovy

  String apiUrl = ExecutionUtil.getProcessProperty(componentId, "api_base_url");
  if (apiUrl.contains("SET_THIS") || apiUrl.contains("dev")) {
      throw new Exception("Production API URL not configured correctly");
  }

Pitfall 2: Not Updating Extensions After Component Changes

Problem:

1. Add new property to component
2. Deploy updated process
3. New property not visible in Extensions
4. Process fails with null value

Solution:

After deploying an updated process, always review Environment Extensions
New properties require extension configuration
Document required extension updates in release notes:

markdown

  ## Release v2.3 - Action Required
  
  New property added: api_retry_delay
  
  Required Action:
  1. Go to Runtime Management → Production Environment
  2. Open Environment Extensions
  3. Set api_retry_delay = 5 (recommended)

Pitfall 3: Using Process Properties for Runtime Calculations

Problem:

Using Process Property to store counter that increments each execution
Property value doesn't persist correctly
Counters get out of sync

Solution: Use Dynamic Process Properties (with persistence) for runtime values:

Process Property Components → Configuration (API URLs, settings)
Dynamic Process Properties → Runtime state (counters, timestamps)

Pitfall 4: Overly Generic Property Names

Problem:

Component: Config
  - url
  - timeout
  - host

What URL? What timeout? Which host?

Solution:

Component: Salesforce_API_Config
  - salesforce_api_url
  - salesforce_timeout_seconds
  - salesforce_host

Pitfall 5: Hardcoding Component IDs in Scripts

Problem:

groovy

// Brittle - breaks if component is recreated
String value = ExecutionUtil.getProcessProperty("abc123def", "api_url");

Better Solution:

Use constants at top of script
Document where to find the ID
Consider using naming patterns in comments

groovy

// Component ID for API_Config: abc123def456
// To find: Open component → Revision History → Component ID in URL
final String API_CONFIG_ID = "abc123def456";

String apiUrl = ExecutionUtil.getProcessProperty(API_CONFIG_ID, "api_base_url");

Best Solution:

groovy

// Best practice: Set Property shape before script
// Use Set Properties to load component values into DPPs
// Access DPPs in script instead of direct component access

String apiUrl = ExecutionUtil.getDynamicProcessProperty("API_BASE_URL");

Pitfall 6: Not Handling Type Conversion Errors

Problem:

groovy

String timeoutStr = ExecutionUtil.getProcessProperty(componentId, "timeout");
int timeout = Integer.parseInt(timeoutStr);  // Crashes if value is "abc"

Solution:

groovy

String timeoutStr = ExecutionUtil.getProcessProperty(componentId, "timeout");
int timeout = 30;  // Default value

try {
    timeout = Integer.parseInt(timeoutStr);
} catch (NumberFormatException e) {
    logger.warning("Invalid timeout value: " + timeoutStr + ", using default: 30");
    timeout = 30;
}

// Validate range
if (timeout < 1 || timeout > 300) {
    logger.warning("Timeout " + timeout + " out of range, clamping to 30-300");
    timeout = Math.max(30, Math.min(timeout, 300));
}

When NOT to Use Process Property Components

Despite their benefits, Process Property Components aren’t always the right choice.

Don’t Use When:

1. You Need Runtime-Generated Values

❌ Wrong Tool:

Process Property Component for:
  - Current timestamp
  - Execution ID
  - Record counter during processing

✅ Use Instead: Dynamic Process Properties or Document Properties

2. You Need Document-Specific Values

❌ Wrong Tool:

Process Property for:
  - Individual customer ID from current record
  - Row-specific validation results
  - Per-document routing decisions

✅ Use Instead: Document Properties (scope: single document)

3. The Value Changes Every Execution

❌ Wrong Tool:

Process Property for:
  - "Last processed record ID" that updates each run

✅ Use Instead: Dynamic Process Property with persistence enabled

4. You Need Complex Data Structures

❌ Awkward:

Process Property:
  customer_1_name: John Smith
  customer_1_id: 12345
  customer_2_name: Jane Doe
  customer_2_id: 67890
  (Repeated for 100 customers...)

✅ Use Instead:

Cross Reference Tables for lookups
External database/cache
JSON file loaded at runtime

5. The Value is Highly Sensitive

❌ NEVER:

Process Property:
  database_password: MySecretPass123
  api_secret_key: sk_live_abc123def456

✅ Use Instead:

Connection Components (with encrypted storage)
AWS Secrets Manager / Azure Key Vault
Certificate-based authentication
OAuth tokens (refreshed at runtime)

6. You’re Building a Quick Prototype

Maybe OK: For quick prototypes, DPPs might be faster:

DPP: Quick to create, no component needed
Process Property: Requires component creation first

Prototype → Use DPP for speed
Production → Migrate to Process Property Component

Conclusion

Process Property Components are the foundation of maintainable, scalable Boomi integrations. They transform hardcoded values into flexible configuration, enable seamless multi-environment deployments, and empower non-technical staff to manage settings.

Key Takeaways

Use Process Property Components when: ✅ Configuration values need to change between environments ✅ Multiple processes share the same settings ✅ You want centralized, documented configuration ✅ Non-technical users need to update values ✅ You’re building for long-term maintainability

Remember:

Organize properties into logical, focused components
Use meaningful names and comprehensive help text
Leverage allowed values for controlled options
Always override sensitive values via environment extensions
Never store passwords in Process Properties
Document extension requirements for each environment

Best Practice Pattern:

Create focused components (API_Config, Database_Config, etc.)
Set safe defaults (usually Dev or conservative values)
Document override requirements clearly
Use environment extensions for environment-specific values
Implement validation in Groovy scripts
Maintain deployment checklists

The Golden Rule: If it’s configuration that could change between environments or over time, it belongs in a Process Property Component.

By following these practices, you’ll build integrations that are easier to maintain, simpler to deploy, and more resilient to change—saving you countless hours of debugging and redeployment headaches.

Additional Resources

Have questions about Process Property Components? Share your use cases or challenges in the comments!

Want more Boomi tips? Subscribe to Integration Insider for weekly tutorials and best practices.

Table of Contents

What Are Process Property Components?

Process Property Components vs Dynamic Process Properties

Creating Your First Process Property Component

Step 1: Navigate to Process Library

Step 2: Name Your Component

Step 3: Add Properties

Step 4: Save and Use

Data Types and Configuration Options

Available Data Types

1. String

2. Number

3. Boolean

4. Date

5. Hidden

Configuration Options

Persistence

Help Text

Allowed Values

Real-World Use Cases

Use Case 1: Multi-Environment API Configuration

Component: API_External_Config

Using in HTTP Connector

Environment Extension Values

Use Case 2: Database Connection Configuration

Component: Database_Connection_Config

Using in Database Connector

Groovy Script with Connection Config

Use Case 3: Email Notification Settings

Component: Email_Notification_Config

Using in Email Connector

Environment Overrides

Use Case 4: Feature Flags and Conditional Logic

Component: Feature_Flags

Using Feature Flags in Process Logic

Groovy Script for Complex Feature Logic

Use Case 5: File Processing Configuration

Component: File_Processing_Config

Using in Disk Connector

Groovy Script for File Validation

Use Case 6: Business Rules and Thresholds

Component: Business_Rules_Config

Using in Business Logic

Groovy Script for Discount Calculation

Working with Extensions for Environment-Specific Values

What Are Extensions?

Setting Up Extensions

Step 1: Define Extensions in Your Process

Step 2: Deploy Your Process

Step 3: Set Environment Extensions

Environment Extension Example

Extension Best Practices

Process Property Components in Groovy Scripts

Import Required Class

Retrieving Process Property Values

Setting Process Property Values

Type Conversion

Complete Example: Dynamic Configuration Loading

Handling Missing or Null Values

Best Practices and Design Patterns

1. Organize Properties into Logical Components

2. Naming Conventions

3. Documentation Standards

4. Default Value Strategy

5. Use Allowed Values for Controlled Options

6. Versioning and Change Management

7. Security Best Practices

8. Testing Strategy

Common Pitfalls and How to Avoid Them

Pitfall 1: Forgetting to Override Extensions in Production

Pitfall 2: Not Updating Extensions After Component Changes

Pitfall 3: Using Process Properties for Runtime Calculations

Pitfall 4: Overly Generic Property Names

Pitfall 5: Hardcoding Component IDs in Scripts

Pitfall 6: Not Handling Type Conversion Errors

When NOT to Use Process Property Components

Don’t Use When:

1. You Need Runtime-Generated Values

2. You Need Document-Specific Values

3. The Value Changes Every Execution