Flow Mobile

The moving parts#

Three things cooperate, and each can fail independently:

1. The app (iOS/Android, from the app stores).
2. Your Infohub instance — which the app must be able to reach to show content: Flow Server's address, on a route the phone can use.
3. The Flow Mobile notification service — the NS-Flow-Mobile connector configured like any other notification server (it carries the standard proxy/credential properties), which is what turns a Message Engine message into a push.

The split explains the two classic symptoms: push arrives but content won't open (notification service fine; the phone cannot reach Flow Server) and app works but no pushes (server reachable; the notification service side is the problem).

Reachability, honestly#

The phone needs a network path to Flow Server — which for most plants means one of:

• On the plant/corporate Wi-Fi (or always-on VPN): use the internal FQDN.
• Externally published Flow Server over HTTPS with a certificate the phone trusts — a public-CA certificate, since pushing an internal CA to personal devices rarely happens. The HTTPS article applies in full, with the phone as the least-forgiving client.

Decide which of the two you are offering before rolling the app out; "works in the office, blank at home" is not a defect, it is an unmade decision.

Registration and verification#

First-run registers the user by email, with a verification mail. The failure ladder, in the order tickets hit it:

1. Verification mail never arrives — corporate mail filtering, almost always. Check spam/quarantine; have IT whitelist the sender. The mail comes from Infohub's messaging side, so the address users must expect follows your email notification configuration.
2. "Email could not be identified" — the address typed doesn't match an Infohub user. The account (with that exact email) must exist in Infohub first — see Users, Groups, and Access. Create/correct the user, then register.
3. Verify link errors — links expire; re-request rather than reusing an old mail. Repeated failures with a correct user usually mean the phone can't reach the server half of the flow (point 2 of the moving parts).
4. Wrong or changed phone number/identity — re-register from the app rather than editing around it.

Getting pushes flowing#

Once registered, pushes follow the ordinary alerting chain, so configuration is the standard one:

1. A Flow Mobile notification server exists and is deployed (Deployment view — same rules as every service object; if right-clicking Notification Servers offers nothing to add, the module/package for the NS is missing from the instance — reimport the notification packages).
2. A message channel routes to it, and the user (or their group) subscribes to the channel.
3. The Message Engine is deployed and the message definition fires — test with a manual trigger before blaming the phone.

Then the app-side checks: notifications permitted for the app in the OS, and the device recently opened the app (mobile OSes throttle pushes to long-dormant apps).

Operating notes#

• Tapping a push opens the message content — dashboards/reports render if (and only if) the reachability decision above was made; that is the "notification fine, content spins" case.
• Attachments/images in messages travel with the message and have had platform-specific quirks historically; if one platform's users can't open images the other can, that is app-version territory — update the app before deep-diving the server.
• Who gets what is channel membership, not app configuration — audit it on the channel, where it is enumerable.
• Decommissioning a user: remove them from channels/groups in Infohub; the app without a valid user gets nothing.

The support bundle#

Mobile tickets resolve fastest with: the user's email as configured in Infohub, whether verification completed, the app platform/version, whether Flow Server opens in the phone's browser (the single most diagnostic check — it isolates reachability from app), and whether any user receives pushes (isolates the notification server from the individual).

See also#

• Notification Services
• The Message Engine
• HTTPS and Certificates
• Users, Groups, and Access