Skip to content
Sections
All notes

All notes · Operations

Application Distribution Without Breaking Workflows

Pushing applications is the most visible thing the platform does. The failures are in timing, versions and what gets removed.

Operations · Procedure

Silent installation of the applications people need is the clearest benefit of enrolment. The problems come from how updates and removals are handled.

The operational work behind “Application Distribution Without Breaking Workflows” is often spread across tickets, projects and repeated manual checks. A team reviewing see the service here for productivity software for business can make that effort visible by project and group, while the device-management platform remains the source of truth for technical state and enforcement.

What works well

Required applications installed at enrolment, so the device is useful on day one.

For an independent baseline relevant to “Application Distribution Without Breaking Workflows”, the Microsoft Intune documentation is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.

Optional applications offered through a portal, so people can self-serve without a ticket.

Configuration delivered with the application, so nothing needs setting up by hand.

That combination removes most first-day support contact, and it is worth stating when making the case for the programme.

The update problem

Updating an application while somebody is using it loses their work.

Mid-presentation, mid-call, mid-form.

Schedule updates outside working hours where the platform allows, and defer when the application is in use, which most platforms support and few deployments configure.

Version pinning

Sometimes necessary: an integration breaks on a new version, a vendor has not certified it.

Pinning is legitimate and it decays — pinned versions fall out of support and accumulate vulnerabilities.

Every pin needs a reason and a review date, which is the same discipline as any exception.

Removal

Removing an application removes its data, which may be the only copy of something.

Give notice before removing anything people use.

And check what the removal takes, because "remove application" and "remove application and data" are different options in several platforms and the labels are not always clear.

The portal

A self-service catalogue is the most appreciated part of most programmes and the most neglected.

Keep it curated: a short list that works, not everything anybody ever requested.

And maintain it, because a portal full of broken or outdated entries stops being used.

Licensing

Applications pushed to devices consume licences, and the count drifts as people join and leave.

Reconcile periodically against what is actually assigned.

This is where device management and asset management meet, and neither side usually owns it.

Bandwidth and timing

A large application pushed to a thousand devices at nine in the morning is a network event.

Stagger it, and consider people on metered or roaming connections, which is a real cost on personal devices and a genuine grievance.

What to check

Do updates defer when an application is in use?

Does every version pin have a reason and a review date?

Does your portal contain anything broken?

And does a large push consider people on metered connections?