SyteLine Event System Customization Guide

Event System Architecture and Event Types

SyteLine events operate at two levels: form-level events tied to UI interactions and IDO-level events tied to data operations. Form events include LoadForm, UnloadForm, StdObjectModified, and button click handlers. IDO events fire during CRUD operations through the Infor Data Object layer.

The critical distinction is that IDO events execute regardless of how data is modified, through forms, APIs, or direct IDO calls, making them the more reliable extension point for business logic.

• Use IDO-level events for business logic that must execute regardless of data entry method
• Reserve form-level events for UI-specific behavior like field visibility and validation messages
• Leverage pre-events for validation and data enrichment before transactions commit
• Use post-events for notifications, logging, and triggering downstream processes

Building Robust Event Handlers

NET assemblies registered through the Event System Configuration form. Each handler must follow strict patterns: implement proper error handling to avoid blocking base transactions, respect the event context for accessing and modifying data, and manage database connections through the IDO runtime rather than opening direct connections. Poorly written handlers that throw unhandled exceptions will block the entire transaction chain.

• Always wrap event handler logic in try-catch blocks to prevent blocking base operations
• Access data through the IDO event context, never through direct SQL in event handlers
• Keep event handler execution time under 2 seconds to avoid user-facing timeouts
• Log handler execution details to a custom table for debugging and performance monitoring

Event System Governance and Upgrade Safety

The biggest risk with SyteLine event customizations is losing track of what fires where. Maintain a master event registry documenting every handler, its trigger point, business purpose, and owner. Before any SyteLine upgrade, export the complete event configuration and test every handler against the new version.

2.

• Maintain a master event registry spreadsheet tracking all handlers and their purposes
• Test all event handlers in a sandbox environment before every SyteLine version upgrade
• Version control event handler source code in Git alongside other SyteLine customizations
• Remove orphaned event registrations from decommissioned customizations to reduce overhead