How-toInfor CloudSuite Industrial (SyteLine) Multi-TenantMongoose / Form Editor / Configuration Management

How to Promote Form Customizations from a Test Tenant to Production in CloudSuite Industrial

Question
how to move form customizations from test tenant to production CloudSuite Industrial

Also searched as

  • SyteLine promote form changes test to production multi-tenant
  • export import Mongoose forms between tenants
  • CloudSuite Industrial configuration migration test to live
  • SyteLine form customization lost after refresh tenant

Short answer

In multi-tenant CloudSuite Industrial, form customizations, UDFs and event configuration live in each tenant's configuration, so moving them from test to production is an export and import of that metadata, not a file copy. Build a change list, export the changed objects from the test configuration, import them into production in dependency order, and verify with a scripted smoke test. Record every change, because a tenant refresh can overwrite test work.

Applies to: Infor CloudSuite Industrial (SyteLine) multi-tenant cloud; also applies in concept to single-tenant and on-premises Mongoose configuration

How to promote configuration from test to production

  1. 1Freeze the scope: list every changed form, UDF, event, event handler, user-defined table, report and user-group permission in a change record.
  2. 2Confirm the test and production tenants are on the same release and patch level, since a form that references a field absent in production will fail on import.
  3. 3Export the changed objects from the test tenant using the export functions in Mongoose configuration forms such as Forms, Event Handlers and User Defined Fields, or the supported configuration export your release provides.
  4. 4Review the exported content for hard-coded environment values: tenant names, URLs, email addresses, report server paths or test user names.
  5. 5Import into production in dependency order: UDFs and user-defined tables first, then IDO and event definitions, then forms that reference them, then permissions.
  6. 6Open each changed form in production as a user from each affected role and run the smoke test: open, add a record, save, query, and trigger the event.
  7. 7Record the import, who did it and when, and keep the exported package so you can roll back or rebuild after a tenant refresh.

Where the customization actually lives

A Mongoose form customization is metadata stored in the application's configuration database for that tenant: the form definition, its components, properties, scripts and the grid of fields. UDFs are metadata too, plus the actual data columns they create. Event handlers and actions are rows in the event system tables. Because it is all data, there is no assembly to copy between servers.

That also explains the most common failure. If someone customizes production directly and later the test tenant is refreshed from production, test work in progress disappears. If production is refreshed from a backup, any configuration added since that backup disappears. Treat the exported package as the source of truth, not either tenant.

Dependency order matters

Import objects in the order they depend on each other. A form that shows a UDF will not bind if the UDF does not exist yet. An event handler that calls a custom user-defined IDO will fail validation if that IDO is missing. A permission grant on a form that has not been imported silently does nothing.

A reliable order is: user-defined fields and tables, then custom IDO definitions allowed in your tenant, then events and event handlers, then forms and form scripts, then user group and menu permissions, then reports. Keep this order in your change record so the next person repeats it exactly.

Verifying instead of hoping

After import, compare rather than eyeball. Open the form in both tenants side by side, and check field order, labels, default values, required flags and scripts. For events, trigger the action and confirm the result, such as the notification, the field update or the called method.

Add a short scripted smoke test that a business user can run in ten minutes: create a customer order line, receive a purchase order line, post a job transaction. The goal is to prove the customized forms still behave inside real transactions, not just that they open.

Change record template
ID: CHG-0142   Source tenant: TEST   Target tenant: PRD   Release: same as target
Objects: UDF Item.uf_Grade; Form ItemMaster (custom); Event ItemSaved -> notify QA
Import order: 1 UDF, 2 Event, 3 Form, 4 Permissions
Smoke test: open Item Master, set grade, save, confirm QA notification

Keeping tenants from drifting apart

Drift is the real long-term problem. Over a year, test and production accumulate small unrecorded differences, and then a promotion fails or, worse, succeeds with different behavior. Make production read-only for configuration except through the change process, and require every change to start in test.

Schedule a periodic comparison of the configuration packages. Even a manual export diff once a quarter catches most drift. Also plan for vendor-managed updates: after Infor patches a tenant, re-run the smoke test, because standard forms can change underneath customized ones.

Common pitfalls

  • !Customizing production directly and losing the change on the next refresh or restore.
  • !Importing in the wrong order so forms reference UDFs or events that do not exist yet.
  • !Leaving test-specific values such as email addresses or report paths inside exported event actions.
  • !Promoting between tenants on different release levels.
  • !Skipping permissions, so the form exists in production but nobody can open it.

How an ERP-grounded AI assistant handles this

An AI assistant grounded in SyteLine can diff two configuration exports and summarize in plain language what differs between test and production, flag environment-specific values and propose the import order. SyteRay is aimed at this customization and upgrade work. It produces a change list for a human to approve and does not import anything on its own.

Frequently asked questions

Can I just copy forms between tenants?

Not as files. Form customizations are configuration records stored per tenant, so you move them through export and import functions in the Mongoose configuration forms, or the supported mechanism for your release. Confirm the exact option with Infor documentation for your version.

Why did my test changes disappear?

Most often the test tenant was refreshed from production, which overwrote its configuration. Always keep exported packages and a change record outside the tenant so work in progress can be reapplied.

Do UDFs move with form exports?

Not necessarily. A UDF creates data columns plus metadata, and a form export may only carry the form. Import UDFs first and verify they exist in the target before importing forms that show them.

How often should I compare test and production configuration?

Quarterly is a sensible minimum, and always after a vendor-managed update or a tenant refresh. Compare exports, not screenshots, so field-level differences are visible.

Related

Advanced

What Customizations Are Allowed in CloudSuite Industrial Multi-Tenant?

In the multi-tenant cloud edition of CloudSuite Industrial (SyteLine), customers work through configuration and supported extension points: form customization, user-defined fields, the event system, custom reports, and integration through ION and the IDO REST service. Anything that needs deploying your own server-side binaries or touching the database directly is generally restricted because the infrastructure is shared. Confirm exact limits for your tenant with Infor, since they change by release.

Advanced

How the SyteLine Event System Works for Workflow Notifications

SyteLine's Event Manager lets administrators subscribe to IDO-level events, such as a purchase order being released or a customer credit hold being set, and fire an email, a Mongoose script, or a workflow action without writing an IDO extension. Cloud tenants can extend the same triggers into ION Workflow for multi-step, cross-application approval processes.

Advanced

How to Debug a SyteLine IDO Extension Class in Visual Studio

SyteLine IDO extension classes run inside the server-side IDO runtime, not inside Visual Studio, so breakpoints only hit once you attach the debugger to that process and deploy matching PDB files. Attach to IDORuntime.exe on classic installs or to the w3wp.exe worker process on IIS-hosted CSI, build in Debug configuration, and copy the DLL and PDB together before setting breakpoints.

Error fix

Diagnosing and fixing SyteLine session timeout errors

SyteLine session timeouts come from one of three independent layers: the IDO Data Service session timeout on the app server, the IIS/application pool idle timeout for the web (Mongoose Web) client, or a load balancer/proxy idle timeout in front of a CloudSuite hosted environment. Fixing the wrong layer is the most common mistake - you need to identify which layer is actually expiring the session before changing anything.

Error fix

Fixing SyteLine's 'Object reference not set to an instance of an object' error

This is a generic .NET NullReferenceException surfacing through the SyteLine IDO Runtime, not a SyteLine-specific error code. It almost always means a form, script or IDO method referenced a field, row or object that came back null, usually after a customization, a missing related record, or a view/IDO method call before the form finished loading. Turn on detailed client logging and check the most recent customization or form event first.

Error fix

Resolving SyteLine multi-site replication conflict errors

A replication conflict in SyteLine's multi-site architecture means the same record (commonly an item, customer, or BOM) was changed independently at two sites between replication cycles, and the replication engine could not automatically merge the two versions. Check the replication conflict log first to see which record and which fields collided, then decide which site's version should win before resuming the queue.

AI for ERP

AI for Infor SyteLine and CloudSuite Industrial

Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.

AI for ERP

On-Prem AI for CloudSuite Industrial, Without the Multi-Tenant Cloud Move

Add generative AI to CloudSuite Industrial without moving to Infor's multi-tenant cloud. On-prem private LLM options for CSI, with governance and audit built in.

Stuck on Infor CloudSuite Industrial (SyteLine) Multi-Tenant?

Talk to engineers who work inside Infor CloudSuite Industrial (SyteLine) Multi-Tenant every week, and who build private AI that answers these questions from your own ERP data.