Infor Factory Track Global Parameters: What Each Setting Controls and Why It Matters

Infor Factory Track (IFT) stores its system-wide defaults in a single Global Parameters record. Every transaction on the shop floor, whether it is a labor clock-in, a material issue, a quantity report, or a move between work centers, reads these values before it executes. If a parameter is set incorrectly, every transaction of that type is affected. There is no transaction-level override that compensates for a broken global setting.

This post covers the actual parameters in each functional group, what they control at a technical level, what breaks when they are wrong, and what questions you should answer before setting them. This is not a high-level overview. It is a working reference for administrators, implementation consultants, and operations teams doing hands-on IFT configuration.

Where Global Parameters Live in Factory Track

In Infor Factory Track, global parameters are accessed through the administration menu under System Setup > Global Parameters. The record is a single-row configuration form. Changes take effect immediately for new transactions; in-progress sessions may not pick up the change until the user logs out and back in, depending on how IFT caches session data.

IFT does not version or audit global parameter changes natively. There is no built-in change log that records who changed what and when. Before any configuration session, take a screenshot or manually document each parameter value. This is the only rollback reference you have.

Global parameters interact with three lower-level configuration layers: site parameters, work center parameters, and item-level settings. The general rule is that lower levels override global defaults, but only for the parameters that exist at that level. Some parameters only exist at the global level and cannot be overridden at all.

Labor Tracking Parameters

These parameters control how IFT records direct and indirect labor. They determine what is valid input, how hours are calculated, and what gets posted to Infor CloudSuite Industrial (CSI) as a labor transaction.

Allow Clock-In Without Work Order Assignment

When this is set to Yes, an operator can clock in and begin accumulating time without selecting a work order or operation. The hours collect against the employee ID and the indirect labor code assigned as the default. When set to No, IFT requires a work order and operation selection before the clock-in transaction completes.

The risk of leaving this open: labor hours accumulate without a cost object. When the payroll close runs in CSI, those hours exist in IFT but have no work order to absorb the cost. They either post to a suspense account or fail to post entirely, depending on your CSI configuration. Neither outcome is visible until reconciliation.

Enforce Shift Schedule Validation

When enabled, IFT checks the system clock against the shift schedule assigned to the work center before accepting a clock-in. If the current time falls outside the scheduled window, IFT either rejects the clock-in, accepts it with a warning, or auto-adjusts the recorded start time to the shift boundary, depending on the sub-setting Shift Boundary Behavior.

Auto-adjustment is the most dangerous option. An operator clocking in at 06:48 on a 07:00 shift has their start time silently moved to 07:00. That 12-minute gap disappears from the record. Over a week, across 40 operators, that is not trivial. Set the behavior to Warn and Accept if you need flexibility, not silent auto-correction.

Indirect Labor Code Validation

IFT maintains a list of valid indirect labor codes. The global parameter Require Valid Indirect Code controls whether an operator can enter any text string as an indirect code or must select from a validated list. When this is off, operators can type free-form values that have no mapping in CSI. Those transactions post to IFT but generate posting errors when they reach CSI because no matching account code exists.

The validated list itself is maintained in the Indirect Labor Code master table in IFT. Each code must have a corresponding labor type in CSI. This mapping must be maintained as a joint responsibility between IFT administrators and the CSI finance team. When a code exists in IFT but not in CSI, or vice versa, the posting will fail silently or generate a CSI error log entry that nobody is monitoring.

Overtime Calculation Ownership

This parameter has two options: Calculate in IFT or Defer to Payroll Integration. If set to Calculate in IFT, the system applies overtime logic based on daily or weekly hour thresholds configured in the parameter record itself. If set to Defer, IFT records raw hours only and the payroll system downstream handles the premium calculation.

Running overtime calculation in both systems simultaneously is a configuration error, not a feature. It produces duplicate premium amounts in CSI labor transactions. The correct setup is one owner. Which one depends on whether your payroll system receives IFT data or CSI data. If payroll reads from IFT directly, let IFT calculate. If payroll reads from CSI, defer and let CSI or payroll handle it.

For multi-site deployments, labor parameters also interact with how CSI handles inter-site labor transfers. The Infor CloudSuite Industrial multi-site configuration affects which site absorbs the labor cost when an operator works across sites within a single shift.

Material Control Parameters

Material control parameters govern how IFT handles inventory transactions at the point of production. These include material issues to work orders, returns, and backflush processing.

Lot Control Enforcement

The parameter Require Lot Number on WO Issue controls whether IFT forces lot selection when issuing material to a work order. The options are Always, Item-Controlled, and Never.

Item-Controlled is the most common setting. It means lot tracking is enforced for items where the lot tracking flag is set to Yes in the CSI item master, and skipped for items where it is set to No. This is correct for most operations. The risk with Item-Controlled is that it requires the item master in CSI to be maintained accurately. If a lot-controlled item is set up without the lot flag, IFT will issue it without lot capture, and that gap cannot be reconstructed.

Never is only appropriate for non-regulated, non-serialised, non-traceable items, and even then it is a significant quality risk. Regulatory environments under FDA 21 CFR Part 820, AS9100, or IATF 16949 require lot traceability as a baseline. Setting this to Never in those environments is a compliance failure, not a configuration preference.

Serial Number Capture

Similar to lot control, serial number capture has the options Always, Item-Controlled, and Never. The practical consideration here is volume. If you are issuing serialised components to work orders, requiring serial capture at issue adds significant data entry time per transaction. Some operations handle this by capturing serial numbers at the operation level rather than the issue level. The global parameter must reflect where in the transaction flow the capture happens, not whether it happens.

Backflush Method

This is one of the highest-impact parameters in the material control group. The options are typically Operation Complete, Move, WO Close, and Manual.

Operation Complete triggers a material backflush when an operator reports a quantity complete at a specific operation. Move triggers it when the quantity is moved to the next operation or location. WO Close triggers it when the entire work order is closed. Manual disables automatic backflushing entirely and requires operators to issue materials explicitly.

The correct setting depends on how tightly your BOM matches actual production. If your BOM accurately reflects material consumption per operation, Operation Complete backflushing keeps inventory accurate in near-real-time. If your BOM has known variances or your operations frequently run partial quantities, WO Close is safer because it gives you a single reconciliation point. Manual is appropriate when material consumption is irregular and cannot be predicted from the BOM.

A 2022 benchmarking study by LNS Research identified inaccurate inventory as the most common data quality failure in MES environments, affecting 41% of surveyed manufacturers. Backflush configuration is a primary driver of that inaccuracy because it determines whether the system records what was consumed or what should theoretically have been consumed.

Over-Issue Tolerance

When an operator issues more material to a work order than the BOM quantity calls for, IFT checks this parameter to determine the response. The tolerance is expressed as a percentage. A value of 10 means IFT will accept issues up to 10% above the expected quantity without a warning. Above 10%, it warns or blocks depending on the sub-setting.

Setting this to 0 with a block behavior is strict but creates friction for operations where minor quantity adjustments are routine. Setting it to open-ended accepts any quantity, which eliminates the control entirely. A tolerance of 5 to 10 percent with a warning is a reasonable starting point for most discrete manufacturing environments.

Default Warehouse and Location

IFT uses global default warehouse and location values when an operator does not specify them explicitly during a transaction. If these defaults are not set, IFT either uses a system placeholder or leaves the fields blank. Blank location fields in a material issue create unlocated inventory in CSI. Unlocated inventory shows up in on-hand balances but cannot be picked by CSI’s allocation logic because it has no bin address.

Set these defaults to the actual staging or issue location for your primary production area. If you have multiple production areas with different staging locations, the item-level or work center-level location settings should override the global default for those areas.

Production Reporting and WIP Parameters

These parameters control quantity reporting at work order operations, move transactions, and scrap disposition. They have a direct effect on WIP valuation in CSI because each IFT production transaction drives a CSI inventory or WIP posting.

Over-Reporting Tolerance

Similar to over-issue, this parameter defines the acceptable percentage above the planned quantity for a quantity-complete report at an operation. Setting it to zero with a block behavior prevents operators from reporting more than the work order quantity, which is correct for most environments. The exception is continuous or flow operations where rounding or measurement variation can cause actual quantities to slightly exceed planned.

A misconfigured or absent tolerance allows operators to report 500 against a planned 100 without a warning. IFT accepts the transaction, CSI books the WIP, and the error only surfaces at a physical inventory or when a supervisor reviews the work order. By that point, the incorrect quantity has already been applied to downstream operations.

Operation Auto-Advance

When an operator reports a quantity complete at an operation, IFT can either hold the work order at that operation, advance it automatically to the next operation in the routing, or advance it only if the reported quantity equals the full planned quantity.

If your CSI routing uses the Auto Move flag on operation records, your IFT global parameter must also enable auto-advance. If CSI expects the move and IFT does not trigger it, the work order routing status in CSI falls out of sync with the physical production status on the floor. Work orders appear to be stuck at an operation that has already been completed, and planners act on stale data.

Scrap Disposition Workflow

The parameter Require Disposition Before Scrap Post controls whether a reported scrap quantity is immediately posted to CSI as a scrap transaction or held in a pending state until a quality disposition record is created.

When set to No, scrap is posted immediately. This is appropriate when operators are authorised to confirm scrap at the point of production. When set to Yes, the scrap quantity sits in an IFT disposition queue until a quality reviewer approves it, rejects it, or reclassifies it. The CSI inventory transaction does not post until the disposition is resolved.

The risk of immediate posting: material that may be salvageable gets written off before inspection. The risk of requiring disposition: if the disposition queue is not monitored, scrap balances accumulate in IFT without posting to CSI, and your WIP valuation in CSI does not reflect actual losses until the queue is worked.

The choice depends on your quality process. If you have a formal NCR (nonconforming record) workflow, require disposition. If operators make the final scrap determination at the machine, immediate posting is cleaner. Document which approach you choose and why, because this setting will be questioned during quality audits.

Understanding how scrap and production transactions flow between IFT and CSI also requires understanding the Infor CloudSuite production transaction architecture, particularly how WIP accounts are debited and credited as material moves through operations.

Integration and Transaction Posting Parameters

These parameters control the mechanics of how IFT communicates with CSI. They are the most technically consequential settings in the global parameter record because they determine what happens to transactions when things go wrong.

Transaction Posting Mode

The two options are Real-Time and Batch. Real-time posting sends each IFT transaction to CSI immediately upon completion. Batch posting accumulates transactions in an IFT staging table and sends them in scheduled intervals, typically every 5, 15, or 30 minutes.

Real-time is preferable when CSI data currency matters for planning or scheduling decisions. The trade-off is that it introduces a dependency between IFT availability and CSI availability. If CSI is down, real-time postings fail at the point of transaction. Batch posting insulates the shop floor from CSI downtime because transactions queue in IFT and flush when CSI becomes available.

The correct choice is not universal. Operations running advanced scheduling or finite capacity planning tools that read from CSI need real-time data. Operations where CSI is used primarily for period-end reporting can tolerate batch delays. Make the choice deliberately based on how downstream systems consume CSI data, not based on which option was pre-selected during installation.

Transaction Error Behavior

This is the parameter with the highest risk if left at its default. The options are typically Retry and Queue, Queue on Failure, and Discard on Failure.

Discard on Failure means that if an IFT transaction cannot post to CSI, it is deleted from the IFT transaction log. The operator sees a successful completion on the shop floor device. The transaction never reaches CSI. No error is raised. This is the most dangerous configuration possible, and it appears as a default or recommended setting in some IFT installation guides because it prevents transaction queues from backing up.

Do not use Discard on Failure in a production environment. Set this to Queue on Failure. Failed transactions should land in a reviewable error queue where an administrator can inspect the failure reason, correct the data, and resubmit. The error queue is typically accessible under IFT’s Transaction Management or Integration Monitor section.

Infor’s own implementation guidelines recommend monitoring the IFT error queue on at least a daily basis. In practice, most sites should monitor it every shift, because a single failed transaction type, such as a missing cost center mapping, can fail silently across every transaction of that type for an entire day before anyone notices.

CSI Connection Timeout

This parameter sets the number of seconds IFT waits for a CSI response before treating the transaction as failed. The default in most installations is 30 seconds. For real-time posting in high-volume environments, this can cause shop floor devices to appear to hang during peak load periods if CSI response time exceeds the timeout.

Do not set this arbitrarily low. A timeout of 5 seconds may prevent device hangs but will cause legitimate transactions to fail during normal CSI processing delays. Work with your infrastructure team to measure actual CSI response times under load, then set the timeout to approximately 150% of the 95th percentile response time. That gives you enough buffer without letting failed transactions sit unresolved for too long.

Infor OS Integration Settings

If your IFT deployment routes transactions through Infor OS (formerly Infor ION) rather than directly to CSI, the global parameters include connection settings specific to the Infor OS endpoint: ION API Gateway URL, Authentication Token Configuration, and Document Flow Settings.

In an Infor OS-routed deployment, the transaction error behavior parameter applies to the IFT-to-ION leg, not the ION-to-CSI leg. ION has its own error handling and document retry logic. This means a transaction that IFT successfully delivers to ION may still fail to reach CSI, and that failure will appear in the ION document flow monitor, not in the IFT error queue. Both queues need to be monitored.

The Infor OS document flow and ION API architecture governs how Factory Track transactions move through the middleware layer, which directly affects where errors surface and how they are resolved.

System Security and Session Parameters

These parameters are often treated as IT-only configuration, but they have direct operational consequences on the shop floor.

Session Timeout

IFT session timeout controls how long a device stays logged in after the last user interaction. In shared-terminal environments, a long timeout means the previous operator’s session is still active when the next operator sits down. If the next operator does not notice, they record transactions against the wrong employee ID.

A timeout of 2 to 5 minutes is appropriate for shared terminals. For dedicated devices where a single operator works an entire shift, a longer timeout reduces re-authentication friction. Set it based on the terminal-sharing model, not as a single global value that tries to serve both use cases at once.

Badge Scan Requirement

IFT can require operators to authenticate using a badge scan (barcode or RFID) rather than a keyboard-entered username and password. The global parameter Authentication Method controls this. Badge scan is faster on the shop floor, reduces authentication errors, and creates a cleaner audit trail because it ties every transaction to a physical badge rather than a shared login.

If your organisation uses SSO through Infor Ming.le or Infor OS, badge scan authentication needs to be reconciled with that SSO configuration. IFT badge scan typically uses a separate authentication path that bypasses SSO, which can create security policy conflicts if your IT governance requires all authentication to go through the central identity provider.

Default User Role at Device Level

IFT allows you to assign a default user role to a physical device or terminal. This role determines which transaction types are available on that terminal without additional login steps. A terminal stationed at a grinding work center can be defaulted to the Grinding Operator role, which limits the visible transaction menu to labor clock-in, quantity reporting, and material issue, without exposing work order management or parameter configuration screens.

If default roles are not configured, all terminals show the full IFT transaction menu filtered only by the logged-in user’s role. This is a security and usability problem. Operators should not see configuration options they do not have permission to change; the visual noise increases the chance of accidental navigation.

Configuration Reference: Key Parameters and Their Options

Before You Change Any Global Parameter

Follow this sequence every time, without exception.

• Document the current value before the change. IFT has no native audit log for global parameters.
• Identify every transaction type affected by the parameter. Do not change a backflush setting and only test labor transactions.
• Test in a non-production environment against the transaction types you identified. This includes edge cases, not just the common path.
• Communicate the change to shift supervisors before it goes live. Operators will notice behavioral differences at their terminals.
• Monitor the error queue for the first two shifts after the change. Failed transactions that were previously succeeding will surface immediately if the new parameter setting breaks something.

Aberdeen Group’s MES Value Matrix benchmarking data shows that manufacturers with formal configuration change management processes for their MES were measurably more likely to achieve production efficiency targets than those without. The process does not need to involve a change control board. It needs to involve documentation, testing, and communication. That is achievable for any shop floor team.

Summary

Factory Track global parameters are a small number of settings with outsized operational impact. The highest-risk settings are the ones that fail silently: Transaction Error Behavior set to Discard, lot control set to Never on regulated items, and overtime calculation running in two systems simultaneously. These do not generate visible errors at the point of transaction. They generate bad data that compounds over days or weeks before anyone finds it.

Configuration decisions should be made against specific operational requirements, not left at installation defaults. Default settings are designed to get a demo environment working, not to run a production shop floor. Every setting in the global parameter record should have a documented rationale based on how your shop floor actually operates.

If you are implementing or auditing a Factory Track deployment, Sama Consulting works with manufacturers to configure IFT correctly against real operational requirements, validate integration with CSI and Infor OS, and build the documentation that keeps the configuration defensible over time. Contact us to discuss your specific setup.