What Is IDO (Intelligent Data Object)?
Also known as: Intelligent Data Object, SyteLine IDO, IDOs
Definition
An IDO (Intelligent Data Object) is the middle-tier business object in SyteLine and the Mongoose framework that exposes database tables as named properties, methods, and collections, so forms, mobile apps, and REST clients all read and write data through one governed layer.
IDO (Intelligent Data Object) Explained
Nothing in a properly built SyteLine application talks to SQL Server directly. Forms, the REST and SOAP interfaces, ION connection points, DataViews, and custom integrations all route through IDOs. An IDO definition binds to one primary table or view, optionally joins subcollections, and publishes a list of properties with data types, lengths, and behavior flags. That single definition then serves every consumer, which is why an IDO change ripples everywhere and why IDO design discipline matters so much on large implementations.
Each IDO supports a standard verb set: LoadCollection to read rows with a filter and order-by, UpdateCollection to insert, update, or delete rows, and Invoke to call a named method. Methods are the interesting part. A standard method may be a stored procedure wrapper; a custom method lives in an IDO extension class, written in C# against Infor's extension class API, compiled into an assembly, and registered against the IDO. The runtime handles transaction scope, so an extension method that updates several tables commits or rolls back as a unit.
IDOs are also the integration surface. Infor's IDO Request service accepts REST calls of the form that name the IDO, the properties, and the filter, returning JSON. This is how mobile shop-floor apps, Power BI refreshes, MES connectors, and third-party middleware most commonly read SyteLine data. Because the IDO enforces the same security and site context as the forms, exposing an IDO endpoint is far safer than granting a service account direct SQL access - a distinction that matters enormously to defense contractors under CMMC scrutiny.
The most frequent design error is proliferation. Teams clone an IDO for every minor variation instead of adding properties or using filters, and end up with dozens of near-identical objects that all need regression testing at upgrade. The better pattern is to extend the delivered IDO where Infor supports it, keep custom IDOs prefixed and few, and document every extension class so the upgrade team knows exactly what it is carrying forward.
Why It Matters
- IDOs are the only supported integration path in multi-tenant CloudSuite Industrial, where direct database access is not available at all.
- They enforce site, entity, and user security consistently, so an API consumer cannot see data a form user could not.
- Custom IDO extension classes are the single largest driver of SyteLine upgrade effort and should be inventoried before any version project.
- Well-designed IDOs let one business rule serve forms, mobile, reporting, and middleware instead of being reimplemented three times.
In Practice
A common gotcha: LoadCollection has a record cap governed by configuration, and integrations that ignore it silently retrieve a truncated set. A nightly sync that pulled "all open orders" was quietly stopping at the default row limit for months, so downstream demand looked artificially low. Always paginate explicitly and assert the returned row count against an expected total.
Frequently Asked Questions
What is the difference between an IDO and a database table in SyteLine?
A table stores rows; an IDO is the business object layered on top of it. The IDO adds property metadata, validation, security filtering by site and user, subcollections from joined tables, and callable methods. Applications never query the table directly - they call the IDO, which applies the rules and then issues the SQL on their behalf.
Can I call a SyteLine IDO from an external application?
Yes. Infor exposes IDO Request endpoints over REST and, in older releases, SOAP. An external system authenticates, then issues LoadCollection, UpdateCollection, or Invoke calls naming the IDO, the property list, and a filter. This is the supported integration method for CloudSuite Industrial and the recommended one on-premises, since it preserves application security and business logic.
Related Terms
Mongoose Framework
Mongoose is Infor's metadata-driven application development framework that SyteLine and CloudSuite Industrial are built on. It renders forms, exposes data through IDOs, runs an event system, and lets customers extend or build applications without altering delivered source code.
IDO Collection
An IDO collection in SyteLine is the in-memory set of rows a LoadCollection call returns from an IDO. It holds the property values plus each row's state - unchanged, modified, inserted, or deleted - so the framework knows exactly what to persist on update.
DataView
A DataView in SyteLine is a user-configurable grid that reads data through an IDO, letting users choose columns, apply filters, group and total rows, and export to Excel - producing ad hoc analysis without a developer or a formal report.
Go Deeper
SyteLine Version End-of-Life Risk Assessment
Score your exposure to running an aging or unsupported SyteLine version across support, security, compliance, and skills dimensions.
The SyteLine Mongoose Framework: A Developer Guide
Complete developer guide to the SyteLine Mongoose framework: IDOs, WinStudio forms, application events, and scripting in Infor CloudSuite Industrial.
SyteLine ION API Integration Guide
Step-by-step SyteLine ION API integration guide: API gateway setup, OAuth 2.0 tokens, BODs vs IDO endpoints, and secure on-prem to cloud connections.
Working with IDO (Intelligent Data Object) in a live environment? Our engineers do this every day - and our AI agents automate most of it.