Setting up AirWatch self-service portal for end users

Modern mobility programmes rarely fail because of bad technology. They fail because end users depend on the helpdesk for things they could realistically do themselves, and that dependency quietly drains IT bandwidth. The self-service module inside AirWatch, now folded into the broader Workspace ONE Unified Endpoint Management suite, exists to reverse that pattern. It hands a controlled toolkit back to the user while keeping the security boundaries firmly with the administrator.

Australian enterprises have been quick to adopt this model, largely because the country's bring-your-own-device culture is among the most mature in the Asia-Pacific region. A field engineer at a Pilbara mine site, a clinician rotating between hospitals in Melbourne, and a retail manager in Brisbane all tend to expect the same thing on the phone they already carry: secure access to corporate email, rosters, and apps without ringing the IT team for every reinstall.

This guide walks through the practical steps to configure the self-service portal from a blank console through to a working catalogue your workforce can use. It assumes you already hold administrator rights in Workspace ONE UEM and that your organisation group structure is mapped against at least one Australian business unit.

How the AirWatch self-service portal actually works

The self-service portal is a web front-end that surfaces a curated subset of Workspace ONE UEM capabilities to a named end user. Behind the scenes it draws on the same device records, profiles, and app assignments that administrators manage in the console, but it filters them through a permission model that decides what each user can see, request, or trigger.

In practice the portal handles enrolment, re-enrolment, app installs, lost-device reporting, and selective wipe of corporate data. For organisations with a strong bring-your-own-device stance, this last function is the one that makes legal teams in Sydney and Adelaide comfortable. A leaving employee can fire off their own exit request through the portal, and the workspace partition disappears without a technician needing to touch the handset.

The architecture is straightforward. Workspace ONE UEM acts as the source of truth for devices, identities, and entitlements. The self-service portal reads from that source, and the user authenticates through your identity provider, most commonly Azure AD or Okta. Once authenticated, the portal shows only the apps and actions the administrator has approved for that user's organisational group.

Prerequisites you should settle before touching the console

A clean deployment starts with three quiet decisions: which identity provider to trust, which organisational groups will see the portal, and which platforms to support. Settle these before you open a browser window, because changes later mean rebuilding assignments.

Confirm that your identity provider is reachable from the public internet if your end users will land on the portal from home or from café wi-fi in places like Surry Hills or South Bank. Single sign-on through SAML 2.0 is the cleanest path and avoids separate credentials that users inevitably write on sticky notes.

Next, decide which platforms to expose. Most Australian rollouts include iOS and Android first, with Windows and macOS added once the mobile experience stabilises. Each platform requires its own certificate template, and Apple devices specifically need an APNs certificate issued from the Apple Push Certificates Portal using a corporate Apple ID. Get that sorted early, because Apple can take a working day to approve new certificates and your pilot will stall otherwise.

Finally, audit any existing profiles. Old Exchange ActiveSync policies, leftover VPN payloads, and legacy compliance rules will collide with anything new you push from the portal. Removing them upfront reduces the number of remediation tickets you will field in the first week.

Configuring the Workspace ONE UEM console

Begin inside the Workspace ONE UEM console by navigating to the Accounts section and creating a dedicated administrator role for portal authoring. Resist the temptation to inherit the super-admin role, because every person you add later inherits your privileges. A purpose-built role such as "Self-Service Publisher" keeps the blast radius small.

With the role in place, switch to the Groups & Settings area and enable the User Self-Service module. You will be asked to choose the URL pattern your end users will visit. Keep it short and human-readable, since users in regional centres such as Cairns or Townsville will type it into a browser on a phone hotspot. Something like portal.yourcompany.com.au is far better than the default long identifier.

The next step is binding the identity provider. Point the console at your federation metadata, confirm the claim that will identify end users, and test the round-trip using a non-privileged test account. If that test account fails, every real employee will fail too, so take the time to read the SAML response carefully and to check that the NameID format matches what the console expects.

Building the catalogue of apps and profiles

The catalogue is where administrators spend the most creative energy, and where most Australian rollouts either win or lose user trust. A cluttered catalogue forces people to ring the helpdesk anyway, which defeats the point of the exercise. The catalogue should mirror the way the business actually works, not the way the IT org chart is drawn.

Group apps by role rather than by department. A roster of cleaners, forklift drivers, and supervisors at a Melbourne distribution centre all need access to the same shift app and the same payslip tool. Bundling these into a "Logistics Worker" catalogue means a single approval gates the whole experience. A useful reference point comes from a real deployment, where one logistics operator chose AirWatch to handle exactly this kind of catalogue, and dramatically reduced the volume of walk-up tickets in the process.

Each app in the catalogue needs an assignment rule. Decide whether it deploys silently, prompts the user, or requires the user to actively install. Healthcare networks in particular favour the prompt approach, because clinicians often carry personal handsets and a silent install on a clinician's personal iPhone raises eyebrows with both the user and the privacy officer.

Localising the experience for Australian teams

Localisation is more than language. Australian users expect date formats, the local currency symbol, and a phone-number layout that matches the way they read it on a payslip. Configure these in the Device Services settings before publishing the catalogue, otherwise you will be patching them in production.

Regional considerations also apply to networking. Workplaces in Western Australia and the Northern Territory often rely on satellite or long-range wireless links, so keep payload sizes modest. A self-service action that quietly pulls a 600-megabyte file in the background will frustrate users far more than a clear prompt that lets them defer the download until they are back on a fixed connection.

Compliance wording deserves attention too. Australia amended the Privacy Act with the Notifiable Data Breaches scheme, and employees increasingly ask whether their personal data on a personal device is exposed during a wipe. Provide a short, plain-English explanation in the portal itself, and link it to your broader corporate privacy statement. This single step answers most of the questions that would otherwise land in the service-desk queue.

Communicating the rollout and training end users

The technology can be flawless and still fail at launch, because end users rarely read emails that look like policy documents. Build a launch campaign that explains the value in terms of what users actually care about: faster access, fewer calls to the helpdesk, and the ability to reset a forgotten PIN without a 40-minute phone call.

Run two pilot waves before the general rollout. The first wave should be the IT team itself, which has the technical curiosity to file useful bug reports. The second wave should be a friendly business unit, such as marketing in Sydney or operations in Perth, where the user population is large enough to surface integration issues without exposing the entire company to a broken experience.

Provide a one-page quick reference card rather than a 30-page manual. Cards circulate on noticeboards in warehouses and break rooms where PDFs do not. Include the portal URL, a QR code, and three screenshots that cover the most common tasks: installing an app, reporting a lost device, and requesting access to a new tool.

Monitoring adoption and tightening the configuration

A successful launch is not the end of the project. The first 30 days reveal patterns that the design phase could not have predicted, and a disciplined review cadence captures them before they harden into accepted behaviour.

Watch the helpdesk for tickets that the portal should have deflected. A steady trickle of "How do I install the timesheet app?" tickets a month after launch is a sign that an app sits in the wrong section of the catalogue or that the assignment rule is silently failing. Pull the reports from the console, map them to tickets, and prune ruthlessly. Many Australian IT leads schedule this review as a monthly 30-minute slot, which is enough to catch drift without becoming a project of its own.

Pay attention to authentication failures as well. A spike in failed sign-ins from a single region, or from a specific device model, usually points to a configuration gap rather than a user error. Fixing the configuration benefits every future enrolment in that group, which is exactly the leverage a self-service model promises.

When the catalogue and the metrics feel stable, your self-service portal has effectively become the first line of mobility support across the business, with the helpdesk reserved for problems that genuinely deserve human attention.

Ready to see how the platform behaves under your own workloads and policies? Start the fully featured 30-day trial, compare the available packages side by side, or speak with a specialist who can map the steps above to your exact organisational structure.