# How to Add a Custom Method to a SyteLine IDO in C# > Source: https://netray.co/erp-help/syteline-custom-ido-method-csharp-how-to > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Custom IDO methods let you expose new server-side business logic - beyond the standard Load, Update, and Delete - as a named, callable operation from the SyteLine client, a script, or an external integration. You declare the method and its parameters on the IDO Collection, then implement it in an extension class that handles invoke calls for that method name. ## Kind advanced ## System syteline ## Erp Infor SyteLine (CloudSuite Industrial) ## Module Customization - IDO Methods ## Query How to add a custom IDO method in SyteLine using C# ## Alternate Queries - create custom ido method syteline - syteline add method to ido collection - csi custom business logic c# method - syteline ido method invoke custom code ## Applies To SyteLine 8.x, 9.x, CloudSuite Industrial (CSI) 10.x ## Steps ### Expose a new server-side method on an IDO **Items:** Open IDO Collections and locate the IDO you want to extend; confirm it already has an Extension Assembly and Extension Class configured, or set one up pointing to your custom DLL and class. On the Methods tab of the IDO Collection, add a new method definition: give it a name, mark it as a custom method, and define its input and output parameters. In your C# extension class project, add a method whose name matches the one you defined, following the extension class's invoke pattern so the runtime routes calls for that method name into your code. Write the business logic using the IDO's own data access context so your method shares the same transaction and row locking as the rest of the call, instead of opening a separate ad hoc connection. Return a properly typed result matching the output parameters you defined, and raise IDO-style business errors rather than raw exceptions, so the client shows a normal error dialog instead of an unhandled exception. Compile, deploy the DLL and PDB to the extension bin folder, and recycle the app pool or restart the IDORuntime service so the new method definition and code are both picked up. Call the method from a test script - a direct Invoke against the IDO - before wiring it into a form, button, or external integration, so parameter and error handling are confirmed independently of the UI. ## Sections ### When a custom method is the right tool **Body:** Row-level hooks like BeforeUpdate or AfterInsert fire automatically on every standard operation against an IDO's rows, which makes them a natural fit for validation and defaulting. A custom method is different: it is an explicit, named operation the caller opts into, which suits work that is not a simple side effect of a normal save - a multi-step calculation, a call out to an external service, or a batch operation across several tables performed in one server round trip. Choosing the wrong one usually shows up as awkward code: cramming a multi-table batch operation into a row hook, or building a custom method just to run one piece of field validation that a hook would have handled automatically. ### Parameters and typing **Body:** The Methods tab lets you define input and output parameters with specific types - string, integer, decimal, datetime, and IDO-specific structured types. These declared types have to match what your C# method actually accepts and returns; a mismatch is one of the most common causes of a method that fails to invoke with a generic, unhelpful error rather than a clear type message. Keep the parameter list as narrow as the operation actually needs. A method with a handful of well-typed parameters is far easier to call correctly from a script, a form, or an external integration than one that takes a large, loosely typed structure. ### Transactions and shared context **Body:** Use the IDO's session and transaction context inside your method rather than opening a separate SqlConnection. That way your method's writes commit or roll back together with everything else happening in that same call, and are visible to other logic - row hooks, App Events - running as part of the same operation. A method that opens its own connection can commit independently of the surrounding call, which breaks atomicity and can also deadlock against rows the outer IDO transaction is already holding. ### Calling the method after it's built **Body:** Once defined, a custom method is callable the same way as any built-in IDO method: from a business rule, an App Event action, a custom form's script, a SOAP IDO web-service Invoke call, or, in CSI cloud, an ION API-based integration. That makes it a reusable building block rather than something tied to a single screen, which is worth designing for from the start. ## Pitfalls - Defining the method on the IDO Collection but never redeploying the extension assembly, or vice versa - both sides must match. - Mismatched parameter types between the Methods tab definition and the actual C# signature, which usually surfaces as a generic invoke error. - Opening a separate database connection inside the method instead of using the IDO's transaction context, breaking atomicity with the rest of the call. - Throwing a raw .NET exception instead of an IDO-style business error, which the SyteLine client shows as an unhandled-exception dialog. - Not testing the method independently with a direct Invoke call before wiring it into a form, so UI issues and method issues get confused. - Forgetting that custom methods, like extension classes, must be re-verified after an Infor CSI upgrade or patch. ## Ai Angle SyteRay can scaffold the boilerplate for a new custom IDO method - the Methods tab parameter definitions plus a matching C# stub with the correct invoke signature - from a plain description of what the method should do, so a developer's first pass is business logic rather than reverse-engineering the invoke pattern from an existing example. It can also flag, before deployment, any parameter type mismatch between the IDO Collection definition and the C# method signature. ## Faq ### What is the difference between a custom IDO method and a hook like BeforeUpdate? **Answer:** A hook like BeforeUpdate fires automatically on every standard operation against that IDO's rows. A custom method is a separate, explicitly named operation you define and call on purpose - closer to adding a new function to an API than intercepting an existing one. ### Can a custom IDO method call other IDOs? **Answer:** Yes. Inside the extension class you can access other IDOs through the same server-side session, letting one custom method coordinate logic across multiple business objects in a single transaction instead of requiring several separate round trips from the client. ### Why does my new method not show up when I try to invoke it? **Answer:** Usually the IDO Collection metadata cache has not refreshed, or the app pool or IDORuntime service has not restarted since you deployed the new assembly. Recycle the pool or restart the service, and confirm the method is saved and marked active on the Methods tab. ### Can I call a custom IDO method from outside SyteLine? **Answer:** Yes - once defined, it is callable through the same SOAP IDO web service used for other IDO operations, or through ION API integrations in CSI cloud, the same way built-in methods like Load and Update are called. ## Search terms syteline custom ido method, add method to ido collection, syteline c# extension method, csi custom business logic method, syteline ido invoke custom, syteline methods tab ido collection, syteline extension class method, syteline api custom method --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json