Infor Factory Track Global Parameters

If you administer Infor Factory Track, you already know the Global Parameters form is not a settings page you visit once and forget. It is the control layer that every Shop Floor, Time Track, and Warehouse Mobility transaction checks before it lets an employee clock a job, issue material, or post inventory. Get one checkbox wrong here and the effect does not stay contained to one screen, it ripples across every transaction that inherits from it.

This article is written for people who are already running Factory Track in production. It is not an introduction to what the application is. It is a working reference for how Global Parameters actually behaves, where it sits in the parameter hierarchy, which fields carry the most operational risk, and how to change them without breaking transactions that depend on the current configuration. Every technical claim below is sourced from Infor’s own product documentation at docs.infor.com, referenced inline.

Where Global Parameters Sits in the Configuration Hierarchy

Infor’s documentation defines two categories of parameter forms in Factory Track: parameter definitions forms, which only authorized programmers should touch because they define what settings even exist, and parameter settings forms, which administrators use to configure actual behavior. Global Parameters belongs to the second category, and Infor is explicit that it is the form used to configure parameters that apply to all Infor Factory Track transactions and forms.

That single sentence is the reason Global Parameters deserves more attention than most administrators give it. A change made here is not scoped to one transaction, one warehouse, or one user. It is the default state that every other layer of configuration either inherits or explicitly overrides.

Infor’s Parameters Overview documentation lays out the full hierarchy in order:

The Global Parameters form configures behavior for the entire application. Transaction Set Maintenance configures parameters for individual transactions, allowing a specific transaction to deviate from the global default. Transaction Warehouse Order Type Print Parameters governs label printing at the transaction or warehouse level. User Extensions configures settings scoped to individual users. Warehouse Parameters configures parameters scoped to specific warehouses, and can also override transaction-level settings for that warehouse specifically.

This is documented directly: Infor states that the Global Parameters Setup form is used to create and modify parameter options that will affect all Infor Factory Track transactions, and that administrators then configure the actual values on the Global Parameters form itself.

The precedence behavior matters in practice, and Infor confirms it explicitly in the warehouse configuration documentation: when you configure alternate transaction settings on the Warehouse Parameters form, for transactions performed in this warehouse, these settings will override the settings on the Transaction Set Maintenance form. So the practical inheritance chain runs Global Parameters first, Transaction Set Maintenance second (where it can deviate per transaction), and Warehouse Parameters last (where it can deviate per warehouse, on top of the transaction-level setting). If you are debugging why a transaction behaves differently in one warehouse than in your global configuration, this is the order to check, in this sequence, every time.

If you are building out a multi-site Factory Track environment and want this hierarchy mapped against your actual ERP backend, our Infor LN consulting team handles this exact alignment work for clients running Factory Track against LN, since the parameter behavior shifts slightly depending on which ERP edition you are connected to.

The Caution Infor Builds Into the Form Itself

Before listing the actual parameters, it is worth repeating Infor’s own warning, because it is unusually direct for vendor documentation. Infor states plainly that only programmers who are authorized to customize your application should use the parameter setup forms, and that changes made to these forms can cause your application to function incorrectly.

That caution is aimed at the parameter definitions forms (the ones that define what parameters exist), not the day-to-day settings form most administrators use. But the underlying point still applies to Global Parameters settings: this form does not validate against your live transaction volume before you save. If you flip a parameter that changes how inventory records are kept, the next transaction that runs picks up the new behavior immediately, with no rollback prompt. Treat every Global Parameters change as production-impacting, because it is.

The Global Parameters Fields That Actually Drive Daily Operations

Below are the Global Parameters fields documented by Infor that have the broadest operational impact, drawn directly from the Configuring Global Parameters task topic. These are not theoretical, they are the exact fields Infor instructs administrators to configure on the form.

Inventory and lot behavior

The Added Item Stock Room Location Permanent parameter decides whether a stock location record survives after you move all items out of it. Infor explains the mechanism precisely: if you keep permanent records, a permanent inventory record will continue to associate that location with the item that was stored there. That location will then continue to be recommended as a stock location for that item. If you clear the checkbox and use temporary records instead, the opposite happens, the location stops being recommended the moment it is emptied, and Infor notes that with temporary records, only locations with an existing stock of a given item will be recommended as stock locations for that item.

This sounds like a minor housekeeping setting until you have a warehouse with hundreds of bin locations and pickers relying on system-recommended locations to move fast. Get this wrong and your putaway suggestions either keep recommending empty bins indefinitely, or stop recommending bins the moment they are emptied, neither of which is what most operations actually want without conscious design.

Allow Negative Inventory is the parameter that decides whether material issues can push an item’s quantity below zero. Infor is specific that if you select it, the application logic still has a dependency: if the check box is selected, the logic must check the Syteline parameter. In other words, enabling this in Factory Track is not sufficient on its own in a SyteLine-integrated environment, the corresponding ERP-side parameter has to align, or the behavior will not match what the checkbox implies. This is a common source of “I changed the setting and nothing happened” support tickets, and it is the first thing to check when negative inventory is not behaving as expected after a parameter change.

Decimal precision and rounding

Maximum Decimal Length controls how many decimal places quantity fields will accept before rounding. Infor’s documentation gives a concrete example of the rounding behavior: if you specify 3, a value of 2.44571 will be rounded to 2.446. This is not truncation, it is rounding, which matters if your costing or lot traceability depends on exact quantities. If your organization works with fractional units, weight-based items, or chemical batch quantities, this single field deserves a deliberate decision rather than a default left untouched.

The related SF Quantity Format parameter governs the same kind of decimal precision specifically for Shop Floor forms, and Infor notes it is only applicable if you have the Shop Floor module implemented, meaning it has no effect if Shop Floor is not active in your license configuration.

Resource and job control

Allow Multiuse of Resource determines whether more than one job can run against the same resource simultaneously. Infor’s wording is direct: when this check box is set to yes, multiple jobs can run on the same resource at the same time. When this check box is set to No, only one job is allowed to run on a resource at a time. For shops running shared equipment across multiple work orders, this parameter is the difference between accurate machine utilization reporting and reports that quietly assume exclusivity that does not exist on your floor.

Elapsed Time Cut Off works alongside this. It is documented as the setting that flags a job as an error record once it has run longer than the specified number of hours, and Infor explicitly frames the use case: you can use this parameter to prevent excessive hours from being clocked to a job in the event that an employee forgets to stop it. If your labor variance reports show suspiciously long single-job durations, this parameter, not the labor transaction itself, is usually where the fix belongs.

Display Resource ID and the dependent Allow Job Resources Only parameter control whether the resource ID field appears on transaction forms at all, and if it does, whether the resource list is filtered to only the resources already defined for that job. Infor notes this parameter set is shared logic: time Track transaction forms also uses this parameter, so a change made for Shop Floor visibility purposes will also change what employees see on Time Track screens. This cross-module dependency is easy to miss if you are only thinking about the module you are actively configuring.

Module activation switches

Several Global Parameters fields are not behavioral fine-tuning, they are module on/off switches, and Infor treats them with extra caution language. The TT module is implemented parameter is the clearest example. Infor’s documentation states it directly: the Time Track Implemented parameter significantly changes the way your application operates. You should only select this parameter when you are implementing the Time Track module. Selecting or clearing this parameter under other circumstances may cause your application to behave unpredictably or incorrectly.

This is one of the few places in the Global Parameters documentation where Infor uses the word “unpredictably.” That word choice is intentional. This parameter should be treated as a one-way implementation switch, not something toggled during testing or troubleshooting, because the application’s internal logic branches differently depending on its state, and Infor does not document a clean path back.

Process Labor and the Infor CloudSuite Industrial Time and Attendance implemented parameter follow similar logic, each gating whether an entire category of transactions is processed against your connected ERP. If you support Factory Track across multiple client sites running different ERP backends, this is exactly the kind of parameter mismatch that causes one site’s labor postings to silently stop reaching the ERP while another site’s keep working, because the parameter was set correctly during initial implementation but never revisited during a later ERP version upgrade.

Generic user and PIN security

PIN Required and Allow Generic Employee to End Session work together to control how shared-device, generic-login scenarios behave on the shop floor. Infor documents PIN Required as the setting that forces a PIN number when signing in as a generic user, while Allow Generic Employee to End Session governs whether that same generic-login employee can end their own session. In any facility where a kiosk or shared scanner is logged in under a generic badge rather than individual employee logins, these two parameters are the actual access control layer, and they deserve the same change-management rigor as any other security setting, not a one-time setup-day decision.

Cycle count interaction

Allow Transactions If Cycle Count Record Exists decides whether normal transaction processing is allowed to continue on items that are mid-cycle-count. Infor’s documentation frames the tradeoff cleanly: select it to allow users to perform transactions involving items that are part of a cycle count, or clear it to prevent users from performing transactions involving cycle count items until the cycle count is completed. Warehouses running continuous cycle counts rather than scheduled full counts almost always need this enabled, otherwise normal operations stall every time a count touches a high-velocity item. If you are running Infor WMS-adjacent processes alongside Factory Track and seeing transaction blocks during count cycles, this is the first parameter to review.

How Changes Here Propagate Through Transaction Set Maintenance and Warehouse Parameters

The reason Global Parameters configuration deserves a deliberate change process, rather than ad hoc edits, comes down to how the override chain actually works. Infor’s Configuring Warehouse-Specific Transaction Settings documentation describes the mechanism for warehouse-level overrides directly: administrators can select Copy From Template to pull the general transaction parameter values currently configured for the transaction on the Transaction Set Maintenance form, creating a separate copy of these transaction values for that warehouse.

Here is the part that catches administrators off guard. Once that copy exists, Infor states clearly that the warehouse-specific copy of these parameters will no longer be linked to the general transaction parameter values, so any changes you make to the warehouse-specific parameter values will not affect the general transaction parameter values and vice versa.

This means a Global Parameters change you make today will not automatically reach a warehouse that already has its own copied transaction parameters. If you update a global behavior expecting it to apply everywhere, and one warehouse was set up eighteen months ago with a warehouse-specific copy, that warehouse is now running on a frozen snapshot of the old configuration and will not inherit your update. The only way to find this is to check, warehouse by warehouse, whether a Warehouse Specific flag is set on the transaction in question, which Infor’s documentation confirms is visible directly on the Warehouse Parameters form: any transactions that have the Warehouse Specific check box selected are already using warehouse-specific parameters.

For organizations running Factory Track across multiple plants or distribution centers, this is the single most common cause of “we changed it globally but Plant 3 is still doing it the old way” tickets. Our data migration and system optimization team regularly audits exactly this kind of configuration drift when client environments have grown organically across several go-lives without a documented parameter baseline.

A Practical Change Process for Global Parameters

Given how broad the blast radius of a single change can be, the safest approach treats every Global Parameters edit as a four-step process rather than a quick form save.

First, identify every transaction and warehouse that currently has its own override for the behavior you are about to change. Infor’s documentation makes clear that warehouse-specific copies are intentionally disconnected from the global value once created, so a global change alone will not reach them. Skipping this step is how configuration drift accumulates silently over years.

Second, change the value on the Global Parameters form itself, following the field-by-field guidance Infor provides directly on the Configuring Global Parameters task topic, and save.

Third, revisit any Transaction Set Maintenance entries or Warehouse Parameters entries identified in step one, and decide deliberately whether each should now match the new global value, keep its existing override, or be reset to inherit from the global default again.

Fourth, document the decision. Factory Track’s parameter forms do not maintain a change history visible to administrators in the same way some ERP audit logs do, so the only record of why a parameter is set the way it is will be whatever your team writes down outside the application.

If your organization is running Factory Track without a documented parameter baseline today, or if you inherited a configuration from a prior implementation partner and are not confident what overrides exist where, that is exactly the kind of environment assessment our Factory Track implementation and optimization services are built around, mapping the current state of Global, Transaction, and Warehouse parameters before making any further changes.

Frequently Asked Questions

Why did my Global Parameters change not take effect in one specific warehouse?

This is almost always because that warehouse has a warehouse-specific copy of the transaction parameter, created using the Copy From Template function on the Warehouse Parameters form. Infor’s documentation confirms these copies are deliberately disconnected from the general transaction values once created, so a global-level change will not propagate to them automatically. Check the Warehouse Specific flag on the relevant transaction in that warehouse first.

Does enabling Allow Negative Inventory in Factory Track guarantee negative inventory will be allowed?

Not on its own in a SyteLine-integrated environment. Infor’s documentation notes that when this checkbox is selected, the application logic also checks the corresponding parameter on the SyteLine side. If the two are not aligned, the behavior you expect from the Factory Track checkbox alone will not occur.

Is it safe to toggle the TT module is implemented parameter during testing?

No. Infor’s own caution language on this parameter states that selecting or clearing it outside of an actual Time Track implementation may cause the application to behave unpredictably or incorrectly. It should be treated as a one-time implementation switch, not a toggle for testing different states.

What is the actual difference between permanent and temporary inventory location records?

Permanent records keep a stock location associated with an item even after the location is emptied, so the system continues recommending it. Temporary records are deleted the moment the location is emptied, so only locations currently holding stock of that item get recommended going forward. Infor documents both behaviors explicitly under the Added Item Stock Room Location Permanent parameter.

Why does changing Display Resource ID also affect Time Track screens, when I only meant to change Shop Floor?

Because Infor’s documentation confirms this parameter, along with the dependent Allow Job Resources Only setting, is shared logic used by both Shop Floor and Time Track transaction forms. Any change made for one module’s visibility needs will also apply to the other.

Who should actually be allowed to change Global Parameters in a production environment?

Infor’s documentation distinguishes parameter definitions forms, restricted to authorized programmers, from parameter settings forms, used by administrators. Global Parameters is a settings form, but Infor’s own caution language around specific fields, particularly module-activation switches, suggests that production changes should still go through the same change control rigor as a code deployment, not be treated as a routine administrative task.

If you want a second set of eyes on your current Global Parameters configuration, or need help untangling years of accumulated warehouse-specific overrides, reach out to our team and we will walk through exactly where your configuration stands against Infor’s documented defaults.