# Logic Deactivation Session in Infor LN > Source: https://netray.co/erp-help/logic-deactivation-session-in-infor-ln > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Infor LN enforces business rules through the Data Access Layer (DAL), which runs validation and defaulting logic on every insert, update and delete. Logic deactivation is the controlled way to switch selected logic off for a defined scope, typically for a data conversion or a one-off repair, and then back on. Use it sparingly, with a backup, because rows written without logic can break integrity rules. ## Kind advanced ## System infor-ln ## Erp Infor LN ## Module Tools / Data Access Layer ## Query logic deactivation session in infor ln ## Alternate Queries - infor ln deactivate dal logic - infor ln bypass business logic data load - infor ln disable dal hooks ## Applies To Infor LN 10.x (Baan 5 / ERP LN); the session name and location in Tools differ by version, locate it with session search ## Steps ### How to use logic deactivation safely **Items:** - Confirm that a normal route does not exist: an import session, BOD or the standard maintain session usually runs DAL logic and is safer. - Take a database backup or a table export for the tables you will touch, and agree a rollback plan. - Use session search to find the logic deactivation session under Tools and note exactly which table or DAL object it applies to. - Limit the deactivation to the smallest scope: one table, one user or one run, not company-wide. - Run the load or correction, then reactivate logic immediately and record what was done and by whom. - Validate the result with the standard reconcile or check sessions for that module, and review rows for missing defaults or broken links. ## Sections ### What DAL logic does and why you would switch it off **Body:** In LN, business rules for a table live in its DAL object: field validations, default values, referential checks, and hooks that fire before and after a save. Sessions and integrations call the DAL rather than writing to the database directly, which is why a record entered through any route obeys the same rules. That strictness becomes a problem in bulk conversion. Loading millions of historical rows may fail validations that are legitimate for new data but not for legacy data, for example a closed period or an item no longer active. Deactivating specific logic lets the load go through. ### Risks you must manage **Body:** Switching logic off removes the safety net that keeps related tables consistent. Rows can be created without defaults, with orphaned references or with derived fields left empty. Later sessions that assume those invariants may error or produce wrong results far from the original load. Treat it like a database-level change: restrict who can run it, log each use, and reactivate straight after. Where the same outcome can be reached by first fixing master data or opening a closed period temporarily, prefer that. ### Better alternatives to try first **Body:** Use the standard import or BOD route when possible, since it runs the DAL and gives meaningful error messages per row. For mass changes to a field, a maintained conversion session in the module is usually safer than raw writes. If a genuine bypass is unavoidable, load into a copy of the company first, compare counts and sums, and only then repeat in production during a quiet window. ## Pitfalls - Leaving logic deactivated after the load: reactivate and verify in the same change window. - Deactivating company-wide when one table was enough. - Skipping the backup: rows written without logic are hard to unpick by hand. - Using it to hide bad source data instead of cleaning it before the load. ## Ai Angle Netray adds a private AI layer on top of the Infor LN you already run, including on-prem installs. ERPray answers questions in plain language over LN data read-only, shows the query it ran and respects LN roles, so a consultant can ask the question instead of hunting for the session. The model runs on your own GPUs, nothing leaves your network, and any write-back needs a human approval. Cloud-hosted LN works too, but the design is tuned for on-prem and air-gapped sites. For pure navigation questions, LN's own session search and help are often enough. ## Faq ### Is logic deactivation the same as disabling a user's authorisation? **Answer:** No. Authorisations decide who can run a session. Logic deactivation changes whether the DAL business logic runs for writes to a table, which affects data integrity rather than access. ### When is it acceptable to use? **Answer:** Mainly for approved data conversions and exceptional repairs where legacy data cannot satisfy current validations, with a backup, a narrow scope and an audit record. ### Will integrations still validate data? **Answer:** Integrations that go through the DAL validate unless logic is deactivated for that scope. That is why the scope should be as narrow as possible. ### Can I find which tables have deactivated logic? **Answer:** The deactivation session itself should list active deactivations. Check it after each load as part of your sign-off. ## Search terms logic deactivation infor ln, infor ln dal, infor ln data access layer, infor ln data conversion, baan dal hooks, infor ln bypass validation, infor ln data load, infor ln tools session --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json