Devices & Push

Registered Devices

Every device that installs the app registers itself, and that list is your view of where the app actually is.

Where to find it

Architect Panel → Mobile Apps:

• Mobile Canvas — the app, its screens and its settings
• App Builds & Releases — building and submitting
• Mobile Devices — the devices that have installed it

Architect Panel → Configuration:

• Site Settings — the Mobile Apps option group

What is recorded

The device identifier, the user, the platform, its push provider and token, whether push is enabled, the app version and build number, the operating system version, the device model and name, its locale and time zone, whether biometrics are enrolled, when it was first and last seen, its last manifest, and whether it has been revoked and why.

It answers the support questions

"Which version are they running", "when did they last use it", "is push enabled on that phone", "do they have biometrics set up". All of it is on one row, and all of it is the first thing you need when somebody reports a problem.

Start every mobile support conversation here rather than by asking the user.

Version spread is worth watching

A list of app versions in use tells you how quickly your users update, which decides whether you can rely on a new capability. If a quarter of devices are two versions behind, your minimum app version needs to reflect that.

Limit devices per user

An installation-level maximum, defaulting to five. Without it a user accumulates every phone they have ever installed on, each holding a session.

Idle devices expire automatically

Not seen for the configured period and the device expires. That keeps the list meaningful and closes the sessions on phones nobody has any more.

Six months is a reasonable default; shorter if the data is sensitive.

Revocation is the control that matters

A device can be revoked with a reason. That is what you do when a phone is lost, when somebody leaves, or when a device should not have the app.

Revoking records why, which matters afterwards — a device revoked with no reason is a question nobody can answer six months later.

Have a procedure and out-of-hours cover

Phones are lost at weekends. Know who can revoke a device outside working hours, and make sure they can actually reach the console.

Review the list periodically

Devices belonging to people who have left, devices last seen a year ago, users with more devices than they have hands. Each is a small risk and the list is short enough to read.

Worked example

An organisation limits users to three devices with idle expiry at six months, and its service desk starts every mobile query by looking at the device row. A quarterly review found four devices belonging to leavers whose accounts had been disabled but whose devices had not been revoked.

Recommendations

• Start support at the device row.
• Limit devices per user and expire idle ones.
• Always record a revocation reason.
• Include device revocation in your leaver process.

Push to Devices

The app can receive push notifications through the platform’s own delivery, which is a different mechanism from web push.

Where to find it

Architect Panel → Mobile Apps:

• Mobile Canvas — the app, its screens and its settings
• App Builds & Releases — building and submitting
• Mobile Devices — the devices that have installed it

Architect Panel → Configuration:

• Site Settings — the Mobile Apps option group

Two delivery services

iOS delivery goes through Apple’s service and Android through Google’s, each configured at installation level. Every device records which provider it uses and its own token.

What a message carries

A title and body, optional data, a badge count, a sound, a priority and a collapse key. Each send records the provider, the result, the provider’s identifier and any failure reason.

The collapse key prevents pile-ups

Messages sharing a collapse key replace each other rather than stacking. So a device that was off for a day receives the latest status rather than forty notifications about the same job.

Use it for anything that supersedes itself — status changes, counts, reminders about one thing.

Priority is not free

High priority wakes the device and costs battery, and both platforms notice apps that overuse it. Reserve it for things that genuinely cannot wait.

Failures are recorded

Each send stores its result and failure reason, which is how you find devices with dead tokens. A token that fails consistently belongs to an app that was uninstalled, and the device should be tidied up rather than retried forever.

Send few and send useful

The threshold is "would this person want their phone to interrupt them for this". Organisations that notify on everything end up with a workforce that has turned notifications off, and then the one urgent message does not arrive either.

Nothing private in the text

Notifications appear on locked screens. A customer name, an address, a case detail or anything medical is that information displayed to whoever can see the phone.

Say that something has changed and let the person open the app.

Push is best effort

Devices are off, tokens expire, delivery services drop messages. Anything that must reach somebody needs another channel as well — and anything time-critical needs a fallback.

Check the badge count means something

A badge showing a number nobody can clear is worse than no badge. Make sure it corresponds to something the user can actually action and that it goes down when they do.

Worked example

A field app notifies on new job assignment and on cancellation only, using a collapse key per job so a device switched on after a day shows the current state. Text names the job number and nothing else. Failed tokens are reviewed monthly and their devices revoked.

Recommendations

• Use collapse keys for anything that supersedes itself.
• High priority sparingly — platforms notice.
• Nothing private in the notification text.
• Review failed tokens and tidy those devices.