Module 10: Improving Workflow Performance

🎯 Learning Objectives

Upon completion of this module, you will be able to:

List tips and best practices for workflow design and initiation
Construct appropriate conditions to optimize performance
Reduce workflow logging overhead in production
Describe performance issues with After Record Submit processing

Why Performance Matters

While individual performance gains may seem small (milliseconds), they compound significantly when:

Processing thousands or millions of records
Running across many user sessions simultaneously
Executing on high-volume transactions like sales orders

💡 Measurement Tools

Chrome Developer Tools and NetSuite Application Performance Management SuiteApp provide general timing information, but not specific bottleneck identification within workflows.

Workflow Design Best Practices

✅ Tip 1: Adopt Modular Design

Don't try to do too much in one workflow. Break complex processes into smaller, focused workflows. This improves maintainability AND performance.

✅ Tip 2: Separate Client and Server Processing

Create separate workflows for client-triggered actions vs. server-triggered actions. This makes troubleshooting easier and can improve execution efficiency.

✅ Tip 3: Use Sub-Workflows

Parent workflows can initiate child sub-workflows for additional processing. This provides better control over execution order while maintaining modularity.

Workflow Initiation Best Practices

✅ Tip 1: Configure Initiation Conditions

Define conditions that prevent unnecessary workflow initiation. It's better to NOT initiate a workflow than to initiate it and immediately exit because conditions aren't met.

✅ Tip 2: Use Appropriate Event Types and Context

Example: For CSV imports, set Context = "CSV Import" to prevent workflow execution on non-imported records. Only initiate workflows during bulk imports when absolutely necessary.

✅ Tip 3: Avoid "All" as Trigger Type

Selecting "All" can cause unexpected workflow initiation. Always select the most appropriate specific trigger (Before Record Load, Before Record Submit, or After Record Submit).

Condition Best Practices

✅ Tip 1: Limit "Old Record" References

Using "Old Record" in the Value Field causes the server to reload the record from the database during condition evaluation. This adds overhead on every evaluation.

✅ Tip 2: Limit Saved Search Conditions

Saved search evaluation impacts performance—especially when configured on individual action/transition conditions. If needed, configure on workflow initiation so it's evaluated once, not multiple times.

✅ Tip 3: Minimize Join Conditions

Conditions with related record joins become complex SQL queries. Alternatives:

Use SQL formulas for more control
Create custom fields to source values from related records before evaluating

After Record Submit Performance

The Re-Save Problem

When multiple workflows run at After Record Submit, records are reloaded on the server. Additionally:

⚠️ Set Field Value at After Record Submit

Every Set Field Value action at After Record Submit causes the record to be reloaded and re-saved. For data-heavy transactions, this significantly impacts performance!

✅ Solution: Use Before Record Submit

Configure Set Field Value actions at Before Record Submit whenever possible. Changes commit with the original save—no re-save required.

Guard Against Unnecessary Re-Saves

Even at Before Record Submit, add conditions to prevent unnecessary Set Field Value execution:

✅ Best Practice

Add a condition that checks if the field value has actually changed before executing Set Field Value. If the value hasn't changed, skip the action—no re-save triggered.

Logging Best Practices

✅ Disable Logging in Production

When updating Release Status to "Released", uncheck Enable Logging. Logging generates database entries for every action execution—unnecessary overhead in production.

📋 Error Logs Still Generated

Even with logging disabled, server-side errors are still logged. Only event-based (UI) errors are suppressed.

Performance Summary Table

Area	Do This	Avoid This
Design	Modular, focused workflows	One giant workflow
Initiation	Specific triggers with conditions	"All" trigger without conditions
Conditions	Standard conditions, sourced fields	Old Record, saved searches, complex joins
Set Field Value	Before Record Submit	After Record Submit
Logging	Enabled for Testing only	Enabled in Production

🌟 Key Takeaways

Modular design improves both maintainability and performance
Configure initiation conditions to prevent unnecessary workflow execution
Avoid "All" trigger—select specific server triggers
Limit Old Record, saved search, and join conditions
Use Before Record Submit for Set Field Value—avoids re-save
Add conditions to guard against unnecessary field updates
Disable logging in production to reduce database overhead
Small millisecond gains compound across thousands of records!