Operations and business leadership
Business owners, operations or service managers, office leaders, and dispatchers can test whether the proposed handoff reflects the work they need to coordinate.
Customer guide / IFS Mobile Work Order
Is your workflow ready for an IFS mobile-work pilot?
Use this guide with the people who run, support, govern, and measure field work. It turns documented IFS concepts into a practical evidence list without treating a product description as proof that your environment is ready.
Workflow fit
Bring the right questions into the room
The completed buyer-fit assessment treats these as practical evaluation roles, not an IFS-prescribed approval hierarchy. Invite the people who can test the workflow in real conditions and confirm what evidence matters to the business.
Field and office users
Technicians, field workers, dispatchers, coordinators, and office staff should weigh in because they would use the workflow and carry its information through the day.
IT, finance, and compliance
IT or IFS administrators, finance, and compliance stakeholders can surface access, configuration, integration, cost, security, and recordkeeping prerequisites early.
Field conditions and usability
Check connectivity and offline conditions, supported iOS or Android devices, and whether field workers can understand and complete the workflow without paper workarounds.
Documentation and handoff
Define what the work record must carry, such as clear notes, photos, videos, signatures, and other evidence needed by the office or customer.
Synchronization and access
Clarify the existing CMMS and IFS context, synchronization expectations, site access, user access groups, administrator setup, and any configuration prerequisites.
Appointments and communication
Ask where appointment reminders, customer communication channels, or missed appointments create friction; the supplied IFS customer research highlights these as practical evaluation questions.
Baseline measures
Before drawing conclusions, record the current baseline for travel time, scheduling effort, first-time-fix rate, and administrative time per work order.
Documented IFS context
What the source material says IFS can support
These points come from the completed readiness assessment and its cited IFS material. Treat them as capabilities or documented prerequisites to verify against the target release and tenant, not as completed facts about your environment.
IFS Mobile Work-Order Capabilities (25R2, 26R1)
IFS Service MWO and IFS Maintenance MWO are mobile apps for work order management [1]. Mobile users execute Work Assignments or Work Tasks from the Task Pool [1]. Work Assignments and Pool Tasks are created in IFS Cloud and transferred to mobile users [1]. The mobile app works both online and offline, but some features are limited to online only [1]. Resources must be defined as mobile users in Resource Details/Maintenance/Service. A resource used with IFS Mobile Work Order must be set as Mobile User in Company Settings, and the resource must belong to a resource group connected to the task company [2].
Work Assignment status and workflow behavior
Work Assignment status cannot be updated in IFS Work Order Management once it is transferred to Mobile [1]. Only Work Assignment status can be updated from the Mobile Client; Work Task status can be updated automatically as a result of Work Assignment changes [4]. When a Work Task is ready but no Work Assignment exists, the mobile system can automatically create one when the task is transferred to mobile [4]. Workflow statuses can include Accepted, Travel, Waiting at Location, Work Start, Cancel, Pause, Pending Completion, Complete, and Incomplete [4].
Workflow configuration
Configuration is done in Service/Work Management/Mobile Maintenance/Workflow Configuration in IFS Cloud Web [3]. Configuration Types include Work Task and Configured Work Task, with subtypes for Standard, New or Additional Work, and Bundle Tasks [3]. Filters trigger a configuration when a Work Task meets the defined criteria. Configured Work Task actions can be placed in a defined sequence in the Actions Flow tab [3].
Field service workflow and task assignment
Work orders can be assigned to the logged-on user or to an employee suggested by the Scheduling Engine [5]. Work orders or work tasks can be transferred to one or more mobile devices belonging to technicians who work for the service organization of the work-order site and have the IFS Mobile Application installed [5]. Work is executed through Work Assignments connected to Work Tasks [5]. Tasks can be assigned to a technician or a common pool. The first technician accepting a Pool Task becomes its owner; Pool-Keep tasks can be accepted by multiple users [1][4]. Allocated Start and Allocated Finish dates can be modified to re-plan an Assignment [4].
Work Task and Bundle Task management
Bundle Tasks group multiple individual Work Tasks into one piece of work that can be scheduled and executed as one [6]. A Bundle Task can include tasks from Work Orders, calculate duration from its included tasks, define resource demands for a person, crew, or tool, and carry an address and planned start and finish dates [6]. Work Assignments are created for allocated resources and can be executed in IFS Cloud Web or transferred to mobile clients. Bundle Task status drives the status of included tasks, and connected Work Assignments are cancelled when tasks are bundled [6][7].
Integration and data requirements
Parts required on the mobile client must be registered in Mobile Part Basic Data. A mobile user can be connected to an assortment so its parts are available in the mobile application [4]. A mobile user needs site access to the Work Task site through Sites per User. A Request Work Task also requires access through a connected Task User Access Group [1]. Mobile Integration can configure IFS Mobile Work Order integrations with Android third-party apps or web pages, including whether an integration appears on the Home screen or as a Work Task Action [1][4]. Configured Request Task and Configured Work Task configurations, including Bundle Task subtypes, are supported only in the Mobile Work Order solution [9].
Operational readiness lens
Operations managers should assess process, data, mobile readiness, workflow design, and ownership before pilot deployment [8]. Test supported devices and OS versions, connectivity, offline operation, charging, security, authentication, data coverage, camera and GPS needs, and support under real field conditions [8]. Test the full job rather than app login alone: assignment, history, forms or photos, time or parts, completion, and recovery after a connectivity gap [8]. Clean active customer, site, asset, technician, job-type, and open-work-order records before migration [8].
Pilot readiness
Gather evidence before defining the pilot
A pilot decision should be based on records, tests, named owners, and agreed measures. Use each item below as a prompt for evidence a customer team can inspect or reproduce.
01
Mobile users and resource setup
Verify the pilot technicians are Mobile Users, belong to resource groups connected to the task company, and have site access for the work they will perform.
02
Work-task and assignment flow
Walk through how a Work Task reaches a technician or Task Pool, who owns a pooled task after acceptance, when Work Assignments are created, and how dates are re-planned.
03
Workflow and status configuration
Document the Configuration Types, filter criteria, action sequence, and Work Assignment statuses the team will use. Confirm how Work Assignment and Work Task status relate in the mobile flow.
04
Bundle or pooled work
If relevant, test Bundle Task duration, resource demands, planned dates, included-task status, and the ownership rules for Pool and Pool-Keep tasks.
05
Mobile data and access
Verify Mobile Part Basic Data, assortments, Sites per User, Task User Access Groups, and clean customer, site, asset, technician, job-type, and open-work-order records.
06
Integrations and endpoints
Inventory each Mobile Integration or third-party app, its placement, expected return values, endpoint, method, payload, authentication, and the credentials or configuration needed to test it.
07
Devices and connectivity
Test supported devices and operating systems in real field conditions, including coverage gaps, offline behavior, charging, camera or GPS needs, authentication, security, and the no-connectivity support path.
08
Representative end-to-end job
Run a representative job from assignment through completion, including history, forms or photos, time, parts, sign-off, status changes, and recovery after a connectivity gap.
09
Training and process documentation
Prepare technician guidance for devices, authentication, offline behavior, statuses, configured action sequences, escalation, and online-only limits; train the pilot team before field testing.
10
Governance and security
Confirm data ownership, least-necessary mobile access, authentication, device security, data retention, record cleanup, integration credential handling, and lost-device or incorrect-record recovery.
11
Named owners and handoffs
Name owners for resource setup, workflow configuration, data, devices, integrations, training, security, pilot support, and the go-live decision. Record support and recovery handoffs.
12
Baseline measures and decision criteria
Record the current baseline for measures such as travel time, scheduling effort, first-time-fix rate, and administrative time per work order. Agree how pilot success, completion, and go-live will be judged.
Open questions / evidence gaps
What this guide cannot establish
The items below are unresolved for a customer environment unless the team supplies evidence. They are questions to answer, not implied requirements already completed.
Which target IFS tenant, release, enabled modules, and configuration are in scope?
Has an IFS administrator activated the required mobile, workflow, integration, and access configuration?
Which mobile users, resources, resource groups, sites, task companies, and user access groups will participate?
Which devices, operating systems, coverage conditions, offline conditions, camera/GPS needs, and security controls must the pilot support?
Which integration endpoints, expected return parameters, methods, payloads, authentication modes, and credentials are available for testing?
Is pilot data clean and representative across customers, sites, assets, technicians, job types, parts, and open work orders?
Which operational metrics, named support owners, recovery procedures, and handoffs will establish pilot success or go-live readiness? The source assessment does not establish these for a particular team.
Use the source carefully
Not found / failed: What operational metrics and handoff processes support successful mobile field-service execution? Not researched in this run (budget). This checklist is an assessment aid and does not prove that Spindlewick has configured or connected an external IFS account. The cited release details should be checked against the team’s target IFS documentation and tenant before a decision.
Next conversation
Start with the workflow you can describe today
Review the existing public workflow context, then share the job, handoff, or field condition your team wants to evaluate. Sharing context does not create an IFS record, connect an account, commit you to a pilot, or finalize pricing.