How maintenance and reliability teams should use Fiix to build a usable asset hierarchy, control work requests, plan and execute work orders, create preventive maintenance, manage meters and parts, capture field history, and turn completed work into better maintenance decisions.
Fiix has different feature versions, plan tiers, permissions, configurable fields, and administrative settings. Your screens may not look exactly like another site's. This guide therefore focuses on the maintenance semantics behind the software: what each major object is for, what information belongs there, and what operating discipline prevents the CMMS from becoming noise.
| Fiix object or feature | Practical maintenance meaning | Failure mode when poorly governed |
|---|---|---|
| Asset hierarchy | The relationship between locations, equipment, tools, parts, and other maintainable records. | Work is consistently charged to the wrong level, so cost and failure history become misleading. |
| Work request | A reported maintenance need that has not yet been translated into controlled work. | Requesters prescribe repairs instead of describing the observed condition. |
| Work order | The execution record for scope, assignments, tasks, parts, labor, cost, and closeout. | The technician receives a work order that still requires planning from scratch. |
| Task / task group | Individual work steps or reusable groups of standard work. | Generic instructions such as “inspect” or “service” create inconsistent execution. |
| Scheduled maintenance | A reusable maintenance template and trigger structure that generates recurring work. | PMs are scheduled precisely even though the task itself is technically weak. |
| Meter / event | Usage or condition information that can support work triggers and asset history. | Readings are collected without a defined maintenance decision or response. |
| Parts & supplies | Spare-parts master and stock records used to plan and consume material. | Inventory quantity is inaccurate because work orders do not capture actual consumption. |
Fiix organizes locations and assets into a hierarchy. Current Fiix documentation describes locations such as regions, sites, and facilities, with equipment, tools, parts, and other records arranged beneath them. Equipment can also sit beneath other equipment. The purpose is not to build the deepest hierarchy possible. The purpose is to put maintenance history at the level where maintenance decisions are actually made.
Region: North America
└── Site: Denver
└── Facility: Packaging
└── Equipment: Line 03
└── Equipment: Filler
├── Equipment: Product Pump P-301
├── Equipment: Capper Gearbox
└── Equipment: Main DriveGive the same failure scenario to three planners or technicians. If they would select three different asset records, the hierarchy or naming standard is not clear enough.
Fiix provides a work-request process, including a request portal that can allow people without normal Fiix login credentials to report maintenance needs. This is useful for operators, contractors, and other requesters, but the value depends on request quality.
Replace conveyor motor.
The requester has already decided the solution. Maintenance still does not know whether the motor is tripping, overheating, noisy, stalled, or simply suspected.
Conveyor C-12 stopped twice in the last 40 minutes. Overload reset restores operation. Motor casing feels hotter than adjacent conveyor motor. No visible product jam. Line currently running at reduced rate.
This gives maintenance evidence and operating context without manufacturing a diagnosis.
| Element | What good looks like |
|---|---|
| Asset / location | The lowest defensible asset or location associated with the condition. |
| Problem statement | Observable symptom, defect, or requested service. |
| Operating context | When it happens, under what load/condition, whether it is intermittent, and what changed. |
| Consequence | Safety, quality, production, environmental, cost, or availability effect. |
| Evidence | Photo, reading, alarm, noise description, leak location, or other useful field information. |
| Temporary action | Any reset, bypass, containment, reduced rate, or other temporary action already taken. |
Fiix work orders can carry asset references, work-order details, tasks, assignments, labor, parts, attachments, costs, completion details, and other configured information. In practical terms, the work order should turn a maintenance need into executable work and preserve what actually happened afterward.
Correct asset, clear scope, priority, responsible person or team, planned labor, required tasks, parts, tools, references, access requirements, and expected completion criteria.
Actual findings, task results, labor, parts consumption, photos, meter readings, discovered work, and changes to the original plan.
Observed failure or condition, confirmed finding, corrective action, verification, actual resources, remaining defects, and follow-up work.
If the technician opens the work order and still has to determine what the job is, find the parts, locate the documentation, decide who is needed, and figure out how success will be proven, the work was dispatched. It was not planned.
Planning is not the act of filling every available Fiix field. Planning removes foreseeable execution barriers before labor and equipment access are committed.
| Readiness element | Question the work order should answer | Typical failure if missing |
|---|---|---|
| Scope | What exactly is being done? | Technician diagnoses and plans the job in the field. |
| Asset | Is the work tied to the correct maintainable record? | History lands on a parent location or wrong equipment. |
| Safety | What hazards, isolations, permits, or controls are known? | Work enters the schedule before basic prerequisites are addressed. |
| Labor | Which skills, how many people, and how much planned effort? | Schedule loading has little relationship to real crew capacity. |
| Parts | What parts are required and are they available? | Technician waits on stockroom or emergency purchasing. |
| Tools / information | What special tools, drawings, manuals, procedures, photos, or test equipment are needed? | The job stops after the asset is released. |
| Access / coordination | Can operations, sanitation, quality, contractors, or other groups support the job? | Scheduled work cannot start. |
| Verification | What evidence will prove the job is complete and the asset is acceptable? | “Running” becomes the only completion standard. |
For the full work-management method, use the Maintenance Planning & Scheduling guide and Maintenance Priority Matrix.
Fiix task groups let maintenance teams reuse multiple standard tasks on work orders and scheduled maintenance. That can reduce administrative effort and improve consistency, but only if the task content is technically strong.
Inspect gearbox.
No method, inspection point, acceptance criterion, reading, or required response is defined.
Inspect input and output shaft seals for active leakage. Verify oil level against sight-glass operating range. Record abnormal noise or vibration under normal loaded operation. If leakage exceeds site criterion or oil level is below range, create corrective work before closing the inspection.
Reuse is valuable only when the common standard is actually common. Do not force unlike equipment into the same task group simply to make administration easier.
Fiix Scheduled Maintenance is the recurring-work engine. Current Fiix documentation identifies time-based, meter-reading, and event triggers, along with fixed and floating trigger behavior. Scheduled maintenance can include tasks or task groups that flow into generated work orders.
Use when the maintenance need is legitimately related to calendar time or when a governing requirement specifies a time interval.
Use when exposure such as runtime, distance, cycles, or another accumulated measure is a better predictor of maintenance need.
Use when a defined event should launch standard follow-up work, such as a process upset, outage, or other configured asset event.
| Trigger approach | Practical meaning | When to be careful |
|---|---|---|
| Fixed | Work continues to generate from the defined original interval or starting basis. | Late completion can compress the time between actual maintenance events. |
| Floating | The next interval is based on the prior generated event/date or reading basis described by Fiix. | Repeated late execution can move the maintenance rhythm away from an intended calendar window. |
| Multiple triggers | A scheduled maintenance record can evaluate multiple conditions and be configured around any/all trigger behavior. | Complex trigger logic can become difficult to audit if nobody documents the intended maintenance strategy. |
A PM can generate perfectly on time and still add little reliability value. Before accepting or changing a scheduled-maintenance interval, identify the failure mode or requirement being managed, the task's ability to detect or prevent it, the consequence of failure, and the evidence behind the interval.
For the reliability method behind this, use Preventive Maintenance Optimization and PM Frequency Optimization.
Fiix meters can capture equipment usage and can support scheduled-maintenance triggers where the configured version supports that behavior. Meter readings may be entered from asset records, through meter-reading tasks, batch processes, and mobile workflows depending on permissions and configuration.
Runtime hours, cycles, distance, throughput, strokes, starts, or another exposure measure used to schedule or analyze maintenance.
Temperature, pressure, vibration, thickness, clearance, contamination, or another measurable condition used to determine whether intervention is needed.
The defined action when a reading crosses a limit, changes rapidly, conflicts with expected behavior, or indicates degraded condition.
If the team cannot explain what a meter reading changes about a maintenance decision, the organization may be collecting data without managing a failure mode.
Fiix supports parts and supplies, location-specific stock, planned and actual quantities on work orders, minimum quantities, stock history, and other inventory controls depending on version and plan. In current Fiix work-order documentation, actual part usage reduces the corresponding stock quantity after the work order is saved.
| Inventory element | Maintenance purpose | Common data failure |
|---|---|---|
| Part master | One controlled identity for the spare or supply. | Duplicates make usage and stock appear fragmented. |
| Stock location | Shows where the physical quantity exists. | System inventory says a part exists but nobody can find it. |
| Minimum quantity | Provides a replenishment threshold. | Min/max values are inherited without lead-time, criticality, or demand logic. |
| Planned quantity | Lets the planner reserve or identify job material demand. | Jobs are called ready before required parts are actually available. |
| Actual quantity | Captures real work-order consumption and updates history. | Technicians use parts but never record them, corrupting both stock and asset cost. |
| Asset BOM association | Helps identify likely parts for the equipment. | BOM is treated as complete even when the field population is weak. |
Fiix's mobile app supports maintenance work in the field and can operate offline for supported workflows. Depending on permissions and configuration, technicians can access assets, work orders, tasks, parts, meter readings, files, and other execution information from phones or tablets.
Asset identification, scope, tasks, attachments, parts, history, and other approved information should be available before the technician starts wrenching.
Record task results, labor, parts, meter readings, photos, findings, and changes while the evidence is still fresh.
Confirm that the work-order history explains what was found, what was changed, how the result was verified, and what still needs follow-up.
Mobile access should reduce duplicate entry and memory-based closeout. If technicians still write everything on paper and reconstruct the job at the end of shift, the workflow is not capturing the main value of mobile CMMS execution.
Fiix can capture work-order completion details, task notes, labor, parts, attachments, and, on supported plans/configurations, failure codes. The maintenance standard should separate observation from interpretation so the history remains defensible.
Replaced bearing. Machine running.
This tells the next person almost nothing about the original symptom, physical evidence, contributing condition, or repair verification.
Symptom: drive-end bearing noise and elevated housing temperature. Finding: inner-race damage and pulley misalignment measured during disassembly. Correction: replaced bearing and realigned pulley. Verification: conveyor ran loaded 30 minutes with normal tracking, noise, and temperature trend. Follow-up: alignment recheck created for next planned stop.
Fiix currently supports problem, cause, and action failure-code workflows on eligible Enterprise configurations. Structured coding can make pattern analysis faster, but a mandatory code should never force a technician to invent a root cause that was not confirmed.
Use the full Work Order Closeout Standard for the field-writing method.
Fiix can report on work, labor, assets, parts, maintenance activity, and other configured data. The limiting factor is usually not whether a report exists. It is whether the fields mean the same thing every time they are used.
| Data element | Governance question | Reliability use |
|---|---|---|
| Asset | Does work consistently land at the maintainable level? | Bad actors, recurrence, cost, labor burden, failure frequency. |
| Maintenance type | Are corrective, emergency, preventive, predictive, project, and local categories clearly defined? | Demand mix and reactive-work analysis. |
| Priority | Does priority reflect consequence and time-to-consequence consistently? | Emergency work, schedule disruption, backlog triage. |
| Statuses / timestamps | What does each status actually mean in the site's workflow? | Backlog age, cycle time, scheduling, execution delay. |
| Tasks / inspection results | Are pass/fail or readings tied to a clear technical acceptance criterion? | PM effectiveness and defect discovery. |
| Labor | Are actual hours recorded consistently enough to represent maintenance demand? | Capacity, planning quality, maintainability, cost. |
| Parts | Does actual consumption reflect what left inventory? | Asset cost, parts demand, stocking decisions. |
| Failure codes | Are problem/cause/action codes controlled and evidence-based? | Failure-pattern and cause/action analysis. |
| Completion notes | Can another maintainer understand symptom, finding, correction, and verification? | Repeat failures, troubleshooting, PM optimization, RCA screening. |
Never calculate a sophisticated metric from a Fiix field whose operating meaning is unclear. Define the field, audit how people actually use it, then decide whether the metric is defensible.
Related XRVE resources: Maintenance Planning & Scheduling, PM Optimization, CMMS Data Quality, Work Order Closeout, and CMMS Data Analysis.
This field guide was reviewed against current Fiix and Rockwell Automation documentation available on October 6, 2026. Fiix is actively evolving, including v5/v6 work-order and equipment experiences, mobile releases, plan-specific capabilities, permissions, and configurable maintenance settings. Confirm the behavior in your tenant before using a feature assumption as a maintenance control.
XRVE Reliability is an independent maintenance and reliability resource and is not affiliated with or endorsed by Rockwell Automation or Fiix. Fiix and Rockwell Automation product names and marks referenced here are the property of their respective owners. This guide is practical maintenance-process guidance, not tenant-specific Fiix implementation consulting and not a substitute for your organization's approved configuration, safety controls, procedures, or current vendor documentation.
Use this guide with your planners, supervisors, technicians, reliability team, and Fiix administrator. If your Fiix history is already available, XRVE Reliability can help turn that history into a prioritized view of bad actors, repeat failures, PM opportunities, backlog risk, planning gaps, and data-quality problems.
Run the free Health Check Open the Resources Library