← Back to Blog
NEW

IFS Mobile Work Order Installation Guide for IFS Cloud

IFS Mobile Work Order can look straightforward at first glance. Download the app, point it at your environment, and log in. In practice, a clean setup depends on several moving parts inside IFS Cloud, including permissions, mobile security grants, IAM clients, redirect URIs, push behavior, and platform-specific integration details.

What is included in IFS Mobile Work Order?

IFS Cloud Mobile Work Order includes two separate apps: IFS MWO Maintenance and IFS MWO Service. Internally, these are identified as MaintEngApp and ServiceEngApp.

That detail matters more than it seems. If a customer only plans to use one of the two apps, removing the unused app from the environment can reduce unnecessary synchronization tasks, outbox messages, and related mobile overhead. That is a sensible cleanup step during rollout, especially for teams that want a tighter mobile footprint.

Where users get the apps

IFS Mobile Work Order is distributed through the standard app stores for each supported platform. The practical recommendation is simple: always use the latest version.

  • Android: IFS MWO Maintenance and IFS MWO Service are available through Google Play
  • iOS: both apps are available through the Apple App Store
  • Windows: both apps are available through Microsoft Store

From a support perspective, that means the installation package is the easy part. The real work is in the server-side setup that allows the app to authenticate, synchronize, and expose the right data.

Permissions are the first real checkpoint

A proper Mobile Work Order deployment starts with a dedicated permission set. That permission set needs access to the relevant MWO projections, because projection access is what allows transactions to move from the app back to the IFS server.

It also needs the functional role permission set MOBILE_APP_RUNTIME. Without that, the user may have business permissions in theory but still be unable to log into IFS Cloud Mobile successfully.

After that, the setup still is not finished. The permission set must also be granted the required Security Groups for the mobile app through the Mobile Apps administration area. This is what allows synchronized data to be retrieved and displayed correctly inside the app screens.

Do not forget the admin role

For teams managing IFS Cloud Mobile from the web client, the administrator also needs the MOBILE_APP_ADMIN role permission set. This is what gives full administrative access to the mobile administration features inside Solution Manager.

This is one of those small details that can quietly slow down a project. The mobile team may think the environment is misconfigured when the real problem is simply that the admin account cannot reach the mobile configuration area properly.

Authentication and client activation checklist

On the client side, users activate the app by entering the correct Server URL and signing in with their IFS credentials. But before that step works reliably, the IAM side has to be aligned.

  • Enable the IAM clients IFS_aurena_native and IFS_aurena_native_services
  • Add the redirect URI ifs-ifsmwomaintenance://auth for MWO Maintenance
  • Add the redirect URI ifs-ifsmwoservice://auth for MWO Service

If the identity provider side is incomplete, login and token handoff will fail even if the app is installed correctly and the user account appears valid.

Push setup is not just a toggle

Push messaging in Mobile Work Order depends on the broader mobile synchronization framework and related application parameters. For many teams, the important operational point is group push.

With group push enabled, the environment includes two system users: IFSMAINTENGAPP and IFSSERVICEENGAPP. Sites need to be connected to these users so the correct site-level objects can synchronize.

If a new site is added, changes may not appear immediately. In some cases, the team has to wait for the next group push refresh schedule based on INIT_SCHEDULE, or force the update using Sync Now under Sync Rules.

MS Teams integration needs separate redirect handling

If the customer plans to use MS Teams integration with MWO mobile apps, Azure App Registration also needs the correct redirect URIs. This is platform-specific.

For iOS and Android, the redirect values use the msauth scheme. For Windows, the redirect values use the ms-appx-web pattern tied to the Microsoft AAD broker plugin. This is the kind of detail that can derail sign-in testing if it is missed during setup.

Remote Assistance support has a platform limit

Remote Assistance in the MWO apps is supported on Android and iOS only. Windows is not included for this capability. That should be considered early if remote expert support is part of the customer’s field service or maintenance mobility strategy.

The real implementation takeaway

IFS Mobile Work Order is not difficult because of the app download. It becomes difficult when permission design, security grants, synchronization setup, IAM client configuration, redirect URIs, and site-level push behavior are handled separately instead of as one coordinated rollout. The teams that get this right treat MWO as a full mobile access design exercise, not a simple app install.

Planning an IFS MWO rollout?

If your team wants help validating MWO permissions, mobile security setup, IAM configuration, or rollout readiness, we can help you structure it before it turns into a support issue after go-live.

Talk to IFS Expert