IDO Extension Pattern: The Correct Way to Extend Business Logic
The IDO extension pattern is Infor's supported mechanism for adding custom business logic to SyteLine. IDOExtensionClass, decorate methods with the IDOMethod attribute, and register the assembly in the IDO Extensions form (Menu Path: Application > IDO Extensions). The runtime loads your assembly and binds your methods to the target IDO's method collection.
Context to get the current IDO property values, session information, and transaction scope. Never open direct SqlConnection objects inside IDO extensions. Instead use the LoadCollection, UpdateCollection, and Invoke methods on the IDO runtime context to interact with other IDOs, which preserves transaction integrity and respects security trimming.
- Inherit from Mongoose.IDO.IDOExtensionClass and apply [IDOMethod] attributes to custom methods
- Register assemblies in Application > IDO Extensions form with the target IDO and method bindings
- Use this.Context.Commands.LoadCollection() for data retrieval instead of direct SQL connections
- Access session context through this.Context.SessionInfo for user, site, and configuration details
Form Script Patterns: Client-Side .NET in the Windows Client
NET form scripts that execute client-side for UI logic, field validation, and dynamic form behavior. NET framework version matching the client runtime. The critical distinction is that form scripts have no direct database access; they communicate through the IDO layer via StdObject calls.
Variables for session-scoped state. Common pitfalls include putting business logic in form scripts (which breaks web client parity), blocking the UI thread with synchronous IDO calls, and failing to handle the FormClosing event for cleanup.
- Attach form scripts through the Form Script Manager form, targeting the specific form by name
- Use ThisForm.PrimaryIDOCollection for data access and ThisForm.Components for UI element references
- Never place business logic in form scripts, it will not execute in the web client or API calls
- Use StdObject.InvokeIDO() for asynchronous IDO calls to prevent UI thread blocking
Upgrade-Safe Development and Customization Governance
NET customizations. Every custom assembly must be cataloged in a customization registry that records the assembly name, target IDO or form, methods, dependencies on specific SyteLine APIs, and the business justification. Before any upgrade, compile all custom assemblies against the new SyteLine SDK version and run regression tests.
Forms namespace. Use interface-based programming where possible, and always code against the IDOExtensionClass abstractions rather than concrete Mongoose internal types.
- Maintain a customization registry tracking every assembly, its target IDO, methods, and dependencies
- Compile custom assemblies against each new SyteLine SDK version in a dedicated build pipeline
- Code against IDOExtensionClass interfaces rather than internal Mongoose types that may change
- Use conditional compilation symbols to support multiple SyteLine versions from a single codebase
Try it here, free
SyteLine Customization Technical Debt Scorer
Measure how much upgrade drag, risk, and maintenance cost your SyteLine customizations have accumulated, and learn where to pay it down first.
Building .NET customizations for SyteLine? Our team writes upgrade-safe extensions for enterprise manufacturers, let us review your approach.