# How to Promote Form Customizations from a Test Tenant to Production in CloudSuite Industrial > Source: https://netray.co/erp-help/csi-mongoose-form-customization-promote-test-to-production-tenant > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind how-to ## System syteline ## Erp Infor CloudSuite Industrial (SyteLine) Multi-Tenant ## Module Mongoose / Form Editor / Configuration Management ## Query how to move form customizations from test tenant to production CloudSuite Industrial ## Alternate Queries - 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 ## Applies To Infor CloudSuite Industrial (SyteLine) multi-tenant cloud; also applies in concept to single-tenant and on-premises Mongoose configuration ## Steps ### How to promote configuration from test to production **Items:** - Freeze the scope: list every changed form, UDF, event, event handler, user-defined table, report and user-group permission in a change record. - Confirm 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. - Export 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. - Review the exported content for hard-coded environment values: tenant names, URLs, email addresses, report server paths or test user names. - Import into production in dependency order: UDFs and user-defined tables first, then IDO and event definitions, then forms that reference them, then permissions. - Open 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. - Record the import, who did it and when, and keep the exported package so you can roll back or rebuild after a tenant refresh. ## Sections ### Where the customization actually lives **Body:** 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 **Body:** 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 **Body:** 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. **Code:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Can I just copy forms between tenants? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms SyteLine promote form customization, CloudSuite Industrial test to production, Mongoose form export import, SyteLine configuration migration, SyteLine UDF migrate tenant, CSI tenant refresh lost customization, SyteLine change management cloud, Mongoose event handler export --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json