People join with their devices
A laptop at home. A tablet at the site.
A hybrid colleague reaches private project resources from an approved computer. A field operator uses a supported phone or tablet to open an internal business application. Both belong to the organisation’s logical network, with different grants for the work they do.
Each device is enrolled separately. Servers may join directly; office resources can sit behind a supported gateway. A mobile device is an access client here, not a substitute for a location gateway.
Verify the native release and application protocol on each platform. Mobile operating systems impose background, sleep and VPN constraints. Test cellular/Wi-Fi changes and reconnection; network membership does not guarantee that a running session survives every transition.
See how people and locations join →Worked resource plan
The field laptop
- Source
- Supported roaming endpoint
- Private job
- Reach an approved team resource
- Internet job
- Decide whether to change the default path
- Transition
- Wi-Fi changes, sleep and restoration
Work through the situation
Separate the private job from the internet job.
A field engineer works from changing local networks. They need a private ticketing tool and may also need a controlled default internet path. Those are two independent requirements, even when they use the same laptop.
Resource plan: the field laptop
| Resource | Owner | Intended boundary |
|---|---|---|
| Field laptop | Named engineer | Supported enrolled endpoint |
| Internal ticketing tool | Business operations | Private resource grant |
| Chosen internet gateway | Workspace operator | Assessed default path |
| Local network | Local operator | Separate existing connectivity |
Decide which traffic needs which path
Networks is the direction for the internal tool. Outbound is the direction for changing applicable default internet traffic on a supported endpoint. A known provider source for one workload may instead fit Outbound.
Evaluate transitions, not just the connected screen
Verify the actual native release and the policy on the laptop. Test private application reachability, public and private name resolution, local LAN behaviour and the selected default route. Then test local network changes, disruption, explicit disable and restoration.
Do not infer a universal kill switch or leak-prevention guarantee. Interruption and fallback behaviour must match the verified platform and configured mode. The application’s own login continues to apply to the private tool.
Leave a visible recovery path
Record how the authorised profile is disabled and the previous internet route is restored. Retire the laptop enrollment or remove the private grant when the assignment ends. Inspect observed state after each change.
The Outbound page explains the default-path scope. Networks covers the separate private resource boundary.
If the result is different
Diagnose the boundary before changing it.
The laptop reconnects after a Wi-Fi change.
Check route and DNS reconvergence on the verified native release. Private-resource reachability and default-route behaviour are separate results.
The routing profile pauses while a kill-switch mode is active.
Assess the actual supported failure behaviour before use. Pausing can interrupt internet access until delivery resumes or supported fallback routing is selected.
The worker only needs the internal tool.
Use the approved private resource path if it meets the job. Do not make a default internet-route change a prerequisite for private access.
Acceptance criteria
Three results worth recording.
- Private access
The work resource is reachable with its own application login.
- Route behaviour
The selected profile’s source and DNS are checked on the actual release.
- Restoration
Disabling the profile restores the intended path and reports its result.
This is a worked planning example, not a customer case study or a released installation procedure.