Status Management
Understanding Statuses in timveroOS
The state of a participant or asset—specifically, its position at a particular stage of the business process, including stages that require actions from users or the system—is determined by its status. Status is a critical characteristic that determines what actions should occur with an object at each stage.
Core Status Concepts
Participant/Asset Status Each participant and asset has a status that represents their current position in the business process. This status:
Determines available actions
Controls process progression
Triggers automated workflows
Indicates required interventions
Application Status Applications also have status, but this is an artificial characteristic determined by the statuses of its participants/assets based on the underlying business process logic. The application cannot progress beyond the constraints of its component statuses.
Standard Status Set
Despite process variations, timveroOS commonly uses these standard statuses:
New
Participant/asset is created
No transition actions performed
Example: Generated consent not yet signed
System awaits initial action
In Process
Participant/asset ready for scoring launch
All prerequisites satisfied
System can initiate automated processing
In Underwriting
Scoring process launched
Results not yet received
May indicate error during scoring
Possible manual review requirement
Declined
Rejected based on scoring results or manual underwriting
Process termination status
Triggers decline communications
Void
Participant/collateral nullified
No longer planning to participate
Example: Guarantor has declined participation
Voluntary or administrative removal
Approved
Approved based on scoring results
May require at least one generated offer
Ready for next process stage
Positive assessment completed
Status Change Mechanisms
Status changes occur through two primary mechanisms:
Automated Status Changes
Result from process execution:
Scoring completion with alerts → Declined
Successful evaluation → Approved
Document upload completion → In Process
Workflow execution outcomes
Manual Status Changes
Result from user actions:
Underwriter decisions
Administrative overrides
Exception handling
Process corrections
Application Status Derivation
Application status derives from participant statuses using business logic. Consider this documented example:
Scenario: Application with multiple participants
Borrower status: Approved
Guarantor 1 status: Approved
Guarantor 2 status: KYC
Result: Application status = KYC
Logic: If at least one active participant has KYC status, the application status becomes KYC. This ensures applications cannot progress until all participants meet requirements.
Status Enhancement with Labels
The system supports labels that provide contextual information beyond status:
Application Labels:
"Preliminary offer is transferred" - Generated offers sent to client
"Pending documents" - Mandatory documents required
"Reevaluation error" - Error during credit limit reassessment
Loan Labels:
"In default" - Active loan flagged with default status
Labels operate independently of status, enhancing user understanding without affecting process flow.
Framework Flexibility
While status-driven processes represent the standard approach, the framework supports alternative implementations:
Non-status-based workflows
Custom process orchestration
Flexible state management
Business-specific adaptations
This architectural flexibility enables institutions to implement processes matching their exact requirements.
Configuration Capabilities
Status Definition
The framework allows defining:
Custom status sets
Transition rules
Validation logic
Role-based permissions
Process Integration
Status management integrates with:
Business process stages
Workflow triggers
Document requirements
Notification systems
Practical Implementation Patterns
Pattern 1: Linear Status Flow
Use Case: Simple consumer loans
Sequential status progression
Automated transitions
Clear start-to-finish path
Example Flow: New → In Process → In Underwriting → Approved/Declined
Pattern 2: Parallel Status Management
Use Case: Multi-participant applications
Independent participant statuses
Aggregated application status
Complex dependency rules
Example: Each guarantor progresses independently; application waits for all
Pattern 3: Status with Manual Gates
Use Case: High-value or complex loans
Automated progression to review points
Manual approval requirements
Mixed automation/human decision
Example: Automatic to "Manual Review", then human decision to "Approved"
Status-Driven Automation
Status transitions can trigger automated actions:
Document generation
Workflow execution
Notification dispatch
System integrations
Data updates
This automation ensures consistent process execution and reduces manual intervention.
Implementation Resources
Through the Admin Panel
(No settings in the Admin Panel)
Through the SDK (Step 1)
For advanced requirements:
Entity Checkers - Custom status logic
Form Classes - Status-based forms
Key Considerations
Status Design Principles
Reflect actual business processes
Enable clear progression paths
Support exception handling
Maintain audit trails
Operational Benefits
Complete visibility into process state
Automated workflow progression
Clear action requirements
Consistent process execution
Related Topics
Applications - How status affects applications
Business Process vs Workflow - Status role in processes
Notifications - Status-triggered communications
timveroOS: Intelligent status orchestration for lending operations
Last updated
Was this helpful?