How to Add Custom Business Logic to a SyteLine IDO with an Extension Class

Build and deploy an IDO extension class

1. 1In Application Studio, open the IDO Collection you want to extend (for example CustOrdr) and confirm the Extendable property is enabled so the generated class exposes extension hooks.
2. 2Create a Visual Studio class library project and reference the Mongoose.IDO and Mongoose.Data assemblies from the SyteLine installation's bin folder, matching your SyteLine version exactly.
3. 3Add a class that follows the IDO's extension naming convention (for example CustOrdrExtension) and implement the Before/After event methods you need: BeforeAdd, AfterAdd, BeforeModify, AfterModify, BeforeDelete, AfterDelete.
4. 4Write validation or defaulting logic inside those methods, throwing a business rule exception, not a raw .NET exception, when a save should be rejected so the error surfaces cleanly in the SyteLine UI.
5. 5Build the project in Release mode and confirm there is no version mismatch between the referenced Mongoose assemblies and the target server's installed version.
6. 6Copy the compiled extension DLL to the IDO Runtime's bin directory on the application server, the same folder that holds the generated IDO assemblies.
7. 7Recycle the IDO Runtime application pool in IIS, or restart the IDO Runtime Windows service, then clear the IDO cache so the runtime loads the new extension instead of the cached generated-only class.
8. 8Test through a thin client or Application Studio's test harness before rolling the DLL to other environments, and keep the source extension project under source control per IDO.

Common patterns: validation, defaulting, and cross-IDO calls

public class CustOrdrExtension : CustOrdrExtensionBase
{
    public override void BeforeAdd(IDORuntimeContext ctx, IDORow row)
    {
        if (row.GetString("ShipTo") == null)
            throw new IDOBusinessRuleException("Ship-to is required.");
    }
}

Extension classes vs Mongoose scripts vs Business Rules

Common pitfalls

• !Editing generated IDO code directly instead of using an extension class, so the change disappears on the next regeneration.
• !Referencing the wrong version of Mongoose.IDO.dll during build, producing a DLL that fails to load or throws obscure binding errors at runtime.
• !Forgetting to recycle the IDO Runtime app pool or service after deployment, then assuming the extension is broken when it is simply still running the cached version.
• !Putting slow external calls, web service calls, email sends, inside AfterAdd or AfterModify, which blocks the user's save transaction under load.
• !Throwing a raw .NET exception instead of an IDO business-rule exception, so the end user sees an ugly unhandled error instead of a clean validation message.
• !Not testing the extension against multi-site or intercompany scenarios, where the same IDO method can be called with a different site context than expected.