In SyteLine (Infor CloudSuite Industrial), configuring means using the system's own parameters, codes, and standard options. Customizing means adding or changing forms, fields, reports, or business logic beyond what ships. Configure first, and customize only when a real business need cannot be met any other way, using the supported Mongoose tools. Too many undocumented customizations is one of the most common reasons upgrades become slow and expensive.
Applies to: SyteLine / CloudSuite Industrial 9.x and 10.x. In Infor's multi-tenant cloud, only the supported framework tools are available.
Quick Answer
- Configure first: Parameters and standard features are supported and carry through upgrades.
- Customize with supported tools: User-defined fields, personalizations, event handlers, and extension classes, not direct database changes.
- Ask why before building: Many requests are habits, not requirements.
- Give every customization an owner: And a reason, a test, and a place in a register.
- Review regularly: Retire what nobody uses.
What Is the Difference, Really?
Configuring is choosing the options on a car. Customizing is welding on a new part. Both can be right, but the second needs a mechanic, a plan, and a conversation about what happens at the next service.
In SyteLine, configuration covers things like parameters, product codes, reason codes, order and planning settings, and security roles. Customization is anything that adds to or changes the application's forms, data, or logic.
What Customization Tools Does SyteLine Support?
SyteLine is built on Infor's Mongoose framework, which provides supported ways to extend it. From lightest to heaviest:
- Form personalization: Moving, hiding, or relabeling fields at user, group, or site level. Low risk, but site-level changes still need checking after upgrades.
- User-defined fields: Extra fields stored with standard records. Low to moderate risk, and much safer than adding database columns.
- Event handlers and the Application Event System: Workflows, validations, and notifications triggered by events, often without code.
- IDO extension classes and custom IDOs: Custom business logic in code. Powerful, but needs a developer and testing at every upgrade.
- Custom reports: Common and often necessary, but each one must be retested when the underlying data changes.
The route to avoid is direct database changes: new triggers, modified stored procedures, or altered tables. They bypass the application's logic, are not possible in the multi-tenant cloud, and are the customizations most likely to break at upgrade.
Why Is Over-Customizing So Tempting?
Because each request is small and makes someone happy. Someone prefers the old layout. Someone wants a field relabeled. Someone wants a report that matches the old paper form exactly. Together, they become a system only one person understands.
Copying your old process into new software is the most expensive habit in ERP. You pay to implement the new system, then pay again to make it behave like the old one.
What Should You Ask Before Customizing?
- What problem are we solving? Describe it without naming a solution.
- Can configuration or a standard feature handle it? Ask someone who knows the product well.
- Can the process change instead? Sometimes the better fix is a different step.
- Who will own it? A named person, not a department.
- What happens at upgrade time? How it will be tested, and by whom.
If a request cannot answer the first question clearly, it is not ready.
Are Some Customizations Worth It?
Yes. A document your customers require, an integration with a carrier, a user-defined field for a regulatory requirement, or a workflow that removes real manual effort can all earn their keep. The point is that they are chosen on purpose, built with supported tools, and documented. For how deployment affects what is allowed, see SyteLine vs CloudSuite Industrial.
What Does Over-Customizing Cost Later?
- Slower, riskier upgrades, a theme in 10 questions to ask before you upgrade
- Higher implementation and support effort, as described in what drives implementation cost
- Dependence on one developer or vendor
- Training that has to cover your special cases
- Behavior nobody can explain
How Do You Keep Control?
Keep a simple customization register: what each item does, which tool it uses, why it exists, who asked for it, who maintains it, and when it was last used. Review it at least once a year and before every upgrade. If nobody can say why something exists, it is a candidate for removal.
A Composite Example
This is a composite of a pattern that comes up often, not a single client.
A packaging company wants its order form to look like the old system. First a few fields are moved, then a custom status is added, then a special report is built for one customer. Each takes a few days.
A year later an upgrade is planned and nobody can say which changes are still needed. Testing them takes weeks, and a couple turn out to duplicate standard features that were available all along. A short register, and a rule that every request answers "what problem are we solving?", would have saved most of that effort.
Customization Decision Checklist
- State the problem without naming a solution
- Check configuration and standard features first
- Consider changing the process instead
- Choose the lightest supported tool that works
- Assign a named owner
- Decide how it will be tested at upgrade
- Record it in the customization register
- Review the register yearly and before upgrades
Frequently Asked Questions
Is customizing SyteLine bad?
No. Targeted, documented customizations built with supported tools can be very valuable. The risk is in many small, undocumented changes that nobody owns.
What is the safest way to add a field in SyteLine?
A user-defined field, added through the supported framework tools. It stores data with the standard record without changing the database structure directly.
Who should approve customizations?
A small group that includes operations and IT, so that both the business value and the long-term cost are considered.
What if we already have too many customizations?
Start with an inventory, find what is unused, and retire it. Then rank the rest by importance and risk, and decide which to keep, rebuild, or replace with standard features.
If you are sitting on a pile of customizations and an upgrade is coming, ClearCutOver can help you build the register and decide what to keep.
ClearCutOver is an independent SyteLine resource and is not affiliated with Infor. Infor, SyteLine, and CloudSuite are trademarks of Infor.
Originally published at ClearCutOver. For more technical Infor SyteLine architecture and migration resources, see our guides on 12 Things to Know Before Your First SyteLine Go-Live and Why Won't My Job Close in SyteLine?.
Top comments (0)