# SyteLine Mongoose Customization Deployment Checklist > Source: https://netray.co/tools/syteline-mongoose-customization-deployment-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer Dev to test to production promotion checks for Mongoose forms, IDO metadata, extension class assemblies, SQL objects, events and reports on SyteLine 9 and CSI 10. ## Category developer ## Erp Infor SyteLine ## Audience - Mongoose developer - ERP administrator - Release manager ## Tool **Kind:** checklist **Groups:** #### Forms **Items:** **Text:** List every changed WinStudio form, global object (components, scripts, strings, variables) and the scope it was saved at (site, group or user) **Critical:** true No customizations accidentally saved at user scope on the developer's login Form metadata moved with your agreed method (form export and import, or FormSync where your release uses it) and not by copying database rows Form scripts compiled without errors in the target environment #### IDO metadata **Items:** **Text:** New or changed IDOs, properties and methods exported with App Metadata Transport to an XML file from the source environment **Critical:** true Same XML imported with App Metadata Transport in the target; import only works from a previously exported file Property bindings checked against the target database (custom columns exist before IDO properties that use them) #### Extension classes **Items:** **Text:** Assembly built from the tagged commit in source control, not from a developer's working copy **Critical:** true Assembly version number increased so you can confirm which build is loaded Assembly imported on the IDO Custom Assemblies form in the target **Text:** On the IDOs form, Custom Assembly Name and extension class name and namespace set for each IDO that uses it **Critical:** true IDO metadata cache refreshed or the IDO runtime recycled so the new assembly is loaded #### SQL objects **Items:** **Text:** Custom stored procedures, functions and views scripted from source control, with a matching rollback script **Critical:** true EXTGEN_ procedure overrides reviewed against the standard procedure in the target release, since updates can change the standard signature User defined fields (Uf_ columns) and user extended tables applied before any IDO or form that reads them Permissions on new objects granted to the roles SyteLine uses, matching the source environment #### Events **Items:** Event handlers, actions, event global constants and triggers exported and imported together **Text:** Synchronous, transactional, suspend and ignore failure settings on each handler checked against the design **Critical:** true **Text:** Event global constants set to target environment values (URLs, email addresses, site codes) **Critical:** true Handler sequence checked against other handlers on the same event, including Infor-shipped handlers #### Background tasks and reports **Items:** Background Task Definitions for new reports and utilities created in the target Report RDLs and their stored procedures deployed to the target report location Report Options output formats and Document Types entries in place for new reports #### Verification and rollback **Items:** **Text:** Smoke test each changed form as a normal user, not as an administrator **Critical:** true LogMonitor running during the smoke test with no new errors Event Handler Status or Event Status checked for failures on any new handler **Text:** Rollback package ready: previous metadata XML, previous assembly, SQL rollback script, form export **Critical:** true Deployment record lists every object moved and who approved it **Scoring Note:** A deployment is ready when every critical item is ticked in the target environment, not in development. Missing event global constants and an unchanged assembly version are the two most common reasons a promotion looks complete but behaves like the old build. ## Content **Intro:** This checklist promotes Mongoose customizations in SyteLine 9 and CSI 10 from development to test to production in the order dependencies require. It covers WinStudio forms, IDO metadata, extension class assemblies, SQL objects, events, background tasks and reports. **Sections:** #### How to use it **Body:** Copy the checklist once per release package and export it with the package. Work through groups in the order shown, because the order follows dependencies: database columns before IDO properties, IDO metadata before forms that bind to it, assemblies before IDOs that reference them, constants before event handlers that read them. Run it first for development to test, then again unchanged for test to production. If something had to be fixed by hand in test, it goes back into the package before production. #### Where this lives in Mongoose **Body:** IDO definitions move with App Metadata Transport, which exports metadata to XML and imports a previously exported file. Extension class assemblies are loaded on the IDO Custom Assemblies form, and each IDO points at its assembly through the Custom Assembly Name and extension class fields on the IDOs form. Forms and global objects live in the forms metadata at site, group or user scope. Events, handlers and actions are maintained on the Events and Event Handlers forms, with run results on Event Status and Event Handler Status. **Bullets:** - App Metadata Transport: IDO metadata XML export and import - IDO Custom Assemblies: extension class DLLs - Event Handlers: handler settings and sequence - LogMonitor: runtime errors during smoke tests #### Version differences and gotchas **Body:** Updates can change standard stored procedures, so an EXTGEN_ override that matched the old signature can fail after an update even though nothing in your package changed. Field labels and the exact export method for forms vary between SyteLine 9 and CSI 10 builds, so record which tool you used in the deployment notes. Customizations saved at user scope by a developer are invisible in testing under other logins and get missed. Event global constants often hold environment specific values and must be edited after import. #### How to check the result in the system **Body:** Open each changed form as a normal user in the target and run the scenario the change was built for. Keep LogMonitor open to catch IDO and extension class errors as they happen. Check the assembly version loaded matches the build you tagged. Trigger each new event and look at Event Status for its result. File the exported checklist with the change record. **Cta:** If you want an AI assistant that reads your SyteLine customizations and drafts the deployment list for each release on your own servers, we can set that up. **Faq:** #### What is the Infor Mongoose platform? **Answer:** Mongoose is Infor's application framework that SyteLine and CSI are built on. It provides IDOs (business objects over SQL tables and stored procedures), WinStudio forms, the event system, background task processing through TaskMan, and the IDO request service that REST and SOAP clients call. Customizations are layered on top through metadata, extension classes and SQL. #### How do I move IDO changes between environments? **Answer:** Export the changed IDOs from the source with App Metadata Transport, which writes an XML file, then import that file with App Metadata Transport in the target. Import works only from a previously exported file. Deploy any database columns the IDO properties bind to first, and load extension class assemblies before the IDOs that reference them. #### Why does my new extension class not run after import? **Answer:** Usual causes: the IDO still points at the old assembly or class name, the IDO runtime has not reloaded metadata, or the assembly built is not the version you think. Check Custom Assembly Name and the extension class fields on the IDOs form, raise the assembly version on every build, and recycle the IDO runtime. #### Should user fields go before or after IDO metadata? **Answer:** Before. User defined fields and user extended tables create database columns that IDO properties and form components bind to. If the IDO metadata arrives first, properties point at columns that do not exist yet and loads fail. Apply SQL and user field changes, then IDO metadata, then assemblies, then forms and events. ## Search terms infor mongoose development, infor mongoose platform, mongoose app metadata transport, ido custom assemblies, syteline customization deployment, mongoose extension class, syteline form promotion --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json