Best Practices
Process Design
Keep Processes Focused
Design each process to accomplish a single, well-defined business objective. Avoid creating monolithic processes that try to handle too many scenarios.
| Approach | Recommendation |
|---|---|
| Single Responsibility | Each process should handle one business workflow |
| Sub-Processes | Break complex workflows into smaller, reusable sub-processes |
| Clear Boundaries | Define clear start and end points for each process |
Name Things Clearly
Use descriptive, consistent naming conventions throughout your processes.
| Element | Naming Convention | Good Example | Bad Example |
|---|---|---|---|
| Process | [Action] + [Subject] | "Approve Loan Application" | "Process 1" |
| Stage | [Action] + [Object] | "Review Documents" | "Stage 2" |
| Transition | [Condition Summary] | "If Amount > $50K" | "Path A" |
Design for Failure
Anticipate what can go wrong and design your processes to handle exceptions gracefully.
- ✅ Always define a default transition from every non-terminating stage
- ✅ Include error handling stages for exception scenarios
- ✅ Configure appropriate timeouts and escalations
- ✅ Use validation in On Entering to catch issues early
Stage Configuration
Use Appropriate Assignment Types
Choose the right assignment type based on the nature of the work:
| Scenario | Recommended Assignment | Reason |
|---|---|---|
| Requires specific expertise | User | Ensures qualified person handles it |
| High volume, interchangeable work | Team | Enables workload balancing |
| Needs consensus/multiple approvals | Every Team Member | Captures all required sign-offs |
| Data validation, calculations | System | Faster, consistent, no human delay |
| Cross-functional collaboration | Custom | Parallel work streams |
Set Realistic Due Dates
Configure due dates that reflect actual business expectations:
- ✅ Account for business hours and working days
- ✅ Consider dependencies on external parties
- ✅ Allow buffer for reviews and rework
- ❌ Don't set artificially tight deadlines that will always be missed
Leverage On Entering and On Exiting
Use stage automation strategically:
| Event | Best Used For |
|---|---|
| On Entering | Notifications, status updates, data preparation, launching parallel work |
| On Exiting | Recording outcomes, calculating results, triggering downstream processes |
Keep automation logic in reusable FlowOn Logic Flows rather than duplicating it across stages. This makes maintenance easier and ensures consistency.
Transitions and Routing
Always Have a Default Path
Every non-terminating stage should have a guaranteed exit path. If no conditional transitions match, the process will be stuck.
Order Transitions by Specificity
When using multiple conditional transitions, order them from most specific to least specific:
- Most specific conditions first (highest priority)
- General conditions next
- Default/fallback last (lowest priority)
Use Decision Tables for Complex Logic
When you have multiple conditions with multiple outcomes, use FlowOn Logic Decision Tables instead of chaining many simple transitions:
| Scenario | Approach |
|---|---|
| 2-3 simple conditions | Simple transition guards |
| Multiple factors, many outcomes | Decision Table |
| Sequential yes/no decisions | Decision Tree |
Versioning and Deployment
Test Before Activating
Always validate your process design before deploying to production:
- ✅ Test all possible paths through the process
- ✅ Verify transition guards with different data scenarios
- ✅ Confirm automation executes correctly
- ✅ Check assignments route to correct users/teams
Use Publish for Review Workflows
Take advantage of the two-step publishing model:
| Action | When to Use |
|---|---|
| Publish | When stakeholder review/approval is required before going live |
| Publish & Activate | For quick deployments of tested, validated changes |
Document Version Changes
Maintain a changelog for your processes:
- What changed in each version
- Why the change was made
- Who approved the change
- When it was activated
Performance and Scalability
Enable Tracing Strategically
Tracing provides valuable debugging information but adds overhead:
| Environment | Tracing Recommendation |
|---|---|
| Development | ✅ Always enabled |
| Test/UAT | ✅ Enabled |
| Production (low volume) | ✅ Enabled for audit |
| Production (high volume) | ⚠️ Consider performance impact |
Keep Stages Focused
Avoid putting too much automation in a single stage. If a stage has extensive On Entering and On Exiting logic:
- Consider splitting into multiple stages
- Move complex logic into dedicated system-assigned stages
- Use sub-processes for substantial parallel work
Minimize Loops
While FlowOn BPM supports non-linear flows, excessive looping can indicate process design issues:
- ✅ Analyze stages with frequent revisits
- ✅ Consider adding validation earlier to prevent rework
- ✅ Review if loop is truly necessary or if process can be redesigned
Security and Governance
Apply Least Privilege
Only assign the Process Designer role to users who genuinely need to design processes:
| User Type | Process Designer Role |
|---|---|
| Process designers/architects | ✅ Yes |
| Business analysts (designing) | ✅ Yes |
| End users (completing tasks) | ❌ No |
| Managers (viewing reports) | ❌ No |
Separate Design and Runtime
In production environments, install only the FlowOn BPM runtime solution:
- ✅ Reduces attack surface
- ✅ Prevents accidental modifications
- ✅ Smaller solution footprint
- ✅ Enforces change management through proper deployment
Use Projects for Organization
Group related processes and artifacts into FlowOn Projects:
- Easier to manage permissions
- Simplified deployment (deploy entire project)
- Better organization for large implementations
- Enables reuse of Logic Flows across processes
Monitoring and Maintenance
Review Process Metrics Regularly
Use trace data to monitor process health:
| Metric | What to Look For |
|---|---|
| Average Duration | Increasing times may indicate bottlenecks |
| Overdue Rate | High rates suggest unrealistic due dates or capacity issues |
| Rework Frequency | Frequent loops indicate quality or clarity issues |
| Fault Rate | Rising faults need immediate investigation |
Archive Completed Instances
For high-volume processes, establish a retention policy for completed instances:
- Keep recent instances readily available
- Archive older instances for compliance
- Document retention requirements
Plan for Process Evolution
Processes change over time. Plan for it:
- ✅ Use version control (FlowOn artifacts in source control)
- ✅ Maintain documentation alongside process definitions
- ✅ Review and optimize processes periodically
- ✅ Gather feedback from process participants