Plan, transfer, and safely verify Sophos Mobile task bundles

A task bundle combines several device tasks. Sophos calls this a transaction; that does not guarantee an atomic rollback if a later task fails. In particular, an earlier policy assignment or app action may already have taken effect. The examples differ between the Sophos Mobile and Threat Defense manuals: the full Mobile manual also includes app installation in its setup example, while the Threat Defense edition mentions enrollment and policies. Do not infer identical permissions or task types from a shared menu path.

Draft / approval boundary: The official guides were compared, but no tenant, device, permission scope, or recovery procedure was tested in practice. Before a production transfer, check the edition/license, platform, ownership and management mode, target devices, and potential data loss against your own environment. This document authorizes neither a wipe nor an automatic retry.

Before creating a bundle: establish platform, mode, and consequences

Create a separate bundle for each platform. Do not mix Android and Android Enterprise in one bundle. For Android Enterprise Full device and iOS/iPadOS Full MDM, choose the appropriate enrollment modes and corresponding policies in the respective setup workflows. Choosing an enrollment mode is a prerequisite, not a repair step to take afterward.

Device administrator is an obsolete Android management mode, available in Sophos Mobile only for Android 9 or earlier; it cannot be used for Android 10 or later. The Android Install app and Uninstall policy tasks described below belong to this legacy mode, not Android Enterprise. This is not a recommendation for new enrollments or continued use of old Android versions. Assess existing devices through the separate migration to Android Enterprise workflow; a task bundle does not replace that migration.

Check available task types for each edition and platform in your own tenant before transfer. Threat Defense lists enrollment, policy, message, and unenrollment for Android and ChromeOS bundles; iOS/iPadOS additionally lists Wipe, but not general app deployment. The full Mobile manual includes further platform-dependent tasks. macOS and Windows appear in its task lists, but not in the Threat Defense edition’s task-bundle navigation. The app, profile, and platform-specific selection procedures below apply to the full Mobile edition.

Edition boundary for enrollment and policies: Instructions for Full device, Full MDM, and the initial, mode-matched policy here apply only to the documented setup workflow in the full Mobile edition. For Enroll on Android and iOS/iPadOS, Threat Defense describes an enrollment email; for Assign policy, it describes selecting a policy, without documenting the full-MDM wizard or an iOS policy-type selector. These differences do not prove that individual controls are generally unavailable in every tenant; check the options actually offered in your tenant.

Wipe: clarify data loss and reactivation first

Approve destructive tasks separately. Android, iOS/iPadOS, macOS, and Windows document Wipe with data loss and no user confirmation; Unenroll and Wipe must not be placed in the same bundle. On iOS/iPadOS, the bundle task resets the device to factory settings; iOS User Enrollment does not permit Wipe.

On Windows, the bundle task also resets the device to factory settings and deletes all data on each target device, not just work data. Check Windows support, key custody, and a safe recovery path separately; do not infer current-tenant behavior from an old task table.

The Android bundle tasks page describes Wipe tasks transferred to Android Enterprise work profile devices as removing only the work profile and managed Google Play apps; for other Android devices, it describes a factory reset. The separate single-device Wipe action, by contrast, excludes work profile devices. These are different action interfaces, not confirmation that a bundle Wipe task is selectable in your tenant/mode or how it will run there. Before a factory reset of fully managed Android devices, establish valid FRP accounts and access to their credentials.

Before considering any Mac Wipe, check the target Mac’s current lock state. The guide for the single-device action excludes remotely locked Macs; this does not establish that the bundle task is suitable in that state. If the Mac is remotely locked, do not plan or transfer Wipe. First clarify the authorized unlock/recovery path and the device’s actual state.

The Mac Wipe task sets a six-digit System Lock PIN; the device restarts and erases its hard drive. To unlock the device after this task, the user must enter that Wipe PIN.

Sophos displays the Wipe PIN under Device properties > Unlock passcode on the device page or under Task details > Lock PIN. Distinguish the Wipe PIN from the PIN for a previous remote lock according to the respective task. Knowing a PIN proves neither that the Mac is already unlocked nor that Wipe is possible.

Before approval, establish who can access the PIN and how it will be handed over securely to authorized people; do not check this by performing a test Wipe.

Unenroll is not Wipe, but it removes Sophos Mobile enrollment without device-user confirmation. This applies to the respective bundle task lists for Android, iOS/iPadOS, macOS, Windows, and ChromeOS in the full Mobile manual, and Android, iOS/iPadOS, and ChromeOS in Threat Defense. ChromeOS having no listed Wipe task does not make Unenroll harmless. Before transfer or retransfer, authorize each target device separately against current group membership, assess the loss of management, and establish a re-enrollment path; do not silently repeat the task. Do not equate the separate unenrollment workflow with the bundle task; check the mode-specific consequences and internal safety workflow in the next paragraph.

Before an Unenroll task, establish the consequences for the specific mode. The Sophos unenrollment guide requires a factory reset for fully managed Android Enterprise devices, resetting the entire device. On work-profile devices, the profile is removed and all apps and data within it are deleted. In the older Device administrator mode, by contrast, the Mobile Control device administrator is disabled, server credentials and received data are removed, and Intercept X for Mobile is reset. On iPhone/iPad, policies, managed apps, and MDM certificates are removed and Intercept X is reset; on Macs, policies and MDM certificates are removed. These consequences require approval even if the task is not called Wipe. The separate safety workflow for unenrollment, data removal, and reactivation covers the necessary checks. These single-device workflows do not establish that an Unenroll bundle task can be selected for every Android Enterprise mode or that the task itself automatically performs a factory reset. If suitability is unclear, do not transfer it; reenrollment does not restore deleted data.

Prepare the bundle and check task order

1. In Sophos Mobile, choose Task bundles and the appropriate platform, open Create task bundle, and enter a name and optional description. Each save increments the bundle version. To create a similar bundle, use the blue triangle and select Duplicate; before transfer, recheck the copy’s targets, task types, and any old destructive steps.

2. Use Add task to add the appropriate type and enter the information required for that task. Check parameters and target mode, then confirm with Apply. The task name appears in the Sophos Fusion Self Service Portal when the task bundle is applied; this is not limited to Enroll. For Enroll, use the following wizard workflow instead.

3. Full Mobile edition only: For an enrollment bundle, open Add task > Enroll. The following wizard with Full device or Full MDM and an initial, mode-matched policy belongs to this documented setup workflow, not to the Threat Defense guide:

   • Optionally change the Enroll task name. It should clearly identify the task for users.
   • Choose the management mode: select Full device for fully managed Android Enterprise devices or Full MDM for fully managed iPhones and iPads.
   • On the next page, choose the initial policy within that Enroll task. It is assigned to the device during enrollment. The list shows only policies that match the selected management mode.
   • After selecting the policy, complete the Enroll wizard with Finish.

   Only then, if needed, use Add task > Assign policy to add tasks for further policies; app and message tasks are also optional and depend on platform and mode. The arrows change the installation order.

4. In the full Mobile edition, Ignore app installation failures can let processing continue after an app installation fails in an Android or iOS bundle; the option appears only with Install app or Install managed Google Play app. Decide deliberately whether a subsequent task is safe at all if the app is missing. The Threat Defense creation page does not describe this option or Selectable for compliance actions.

With Enroll on Android, iOS/iPadOS, macOS, Windows, and ChromeOS, the enrollment email goes to the email address configured for the individual device. Check that address before transfer: for a new device, the user must follow the steps in the email. On an already enrolled device, the enrollment task is skipped.

Compliance selection does not configure a response

Selectable for compliance actions makes a bundle available for compliance responses. Transfer on noncompliance is configured in a compliance policy, not by this checkbox alone. A response configured that way can automatically transfer the bundle to devices when they become noncompliant. If the bundle contains Wipe, deletion can also be triggered automatically. This is not an innocuous test option or a recommendation to make Wipe a default response. Rules, target scope, and responses belong in the separate compliance policy planning workflow.

Policy tasks: distinguish selection from silent effects

On Android and ChromeOS, select the desired policy under Assign policy; on iOS/iPadOS in the full Mobile edition, first select the policy type, then a policy of that type. On Android, iOS/iPadOS, and ChromeOS, the policy is assigned silently, without user action, when transferred. On Windows, under Assign policy, select a policy from the list of available device policies; it is assigned silently when transferred and replaces an existing device policy. Do not expect confirmation on the device to serve as an approval step.

On macOS, the task type determines the selection list:

These three Mac tasks silently assign the selected policy when transferred, each replacing an already assigned policy of the same type. User policies take effect only at the next sign-in. Under Assign imported policy, instead select an Apple configuration profile from the profiles already imported into Sophos Mobile; this is a different input source from the three native policy lists.

For Uninstall policy on Android and iOS/iPadOS, select the policy under Select source > Policies. The list includes both policies added to Sophos Mobile and policies installed on any managed device; a list entry alone does not establish that the policy is installed on the intended target. A policy not listed can be addressed using its known identifier.

The limits still apply: Android Uninstall policy is available only when Sophos Mobile is configured for Device administrator management mode and removes only Android device policies or Knox container policies. For iOS Device Enrollment, Uninstall policy removes applicable policies; for User Enrollment, use Unassign iOS user policy instead and select the user policy under Select source > Policies there too. For other policy types, update the policy or assign a different one rather than assuming uninstall always reverses assignment.

Sophos documents under SMCSRV-13800 that renamed profiles may still appear under their old names in profile-removal tasks. Before transfer, verify the identity of the profile intended for removal against the approved inventory and intended assignment, not the displayed name alone. If the mapping remains unclear, do not transfer the bundle; Sophos lists no workaround for this display problem.

Separately, the Sophos Known Issues list checked on October 6, 2026 identifies SMCSRV-13802: Android profiles created with Duplicate in an older Sophos Mobile version cannot be removed through a task bundle. The entry specifies neither an exact affected version nor a fix version and lists no workaround. This concerns those older profiles, not every profile-removal task. If the failure matches, document the profile’s origin and affected step, and ask Sophos Support to establish the supported path for your version; do not bypass it by retransferring the bundle or using an unverified substitute action.

If a required policy is missing from the ChromeOS assignment list, first create it using the internal policy creation and direct assignment workflow. Then return to the bundle task and select the policy there; do not confuse direct assignment with configuring a bundle task.

Plan app tasks by platform

Android: management mode and user decisions

Install app is available only when Sophos Mobile is configured for Device administrator management mode. Select an app from the list of available apps in the task. Android Enterprise instead uses Install managed Google Play app: this type is available only when Android Enterprise is configured and lets you select a managed Google Play app approved for the organization.

If a regular app entry is missing, add it through the app catalog and general deployment workflow. For Android Enterprise, first check the existing organization connection and Play approval in the managed Google Play workflow. That workflow also covers separate installation through Apps - Android Enterprise and Play-specific app removal. The bundle task does not grant catalog approval; Uninstall app below does not replace that Play removal path or its Allow app uninstall check.

For Android Uninstall app, select the target app under Select source > Apps. The list includes apps added to Sophos Mobile or installed on any managed device, but not Android system apps or apps preinstalled by the manufacturer. For an app not listed, select Identifier and enter its package name. Knox container app targets removal from the Samsung Knox container. The identifier is not an established way to bypass these system-app limits.

With Install app and Uninstall app, users receive a notification on the device: OK starts the operation, while Not now postpones it and causes another notification after a short time. If the user selects OK and then taps Cancel in the subsequent Android dialog, the task fails. If the app to be uninstalled is not installed, no notification appears; do not infer a particular success status from that. Install app can update an already installed app. Check the app version and update approval before retransfer as well.

iOS/iPadOS: app targets and enrollment limits

Under Install app, select an app from the available list. In the installation dialog described by the task help, Install starts the operation; Cancel rejects it and the task fails. Do not infer that every iOS distribution mode always prompts the user. For already installed apps, the task can trigger an update. Under Apple User Enrollment, Install app can install only apps purchased through Apple Business.

Before Uninstall app: On the specific iPhone/iPad, check whether the target app is managed under Show device > Installed apps > Managed. Unmanaged apps cannot be uninstalled through Sophos Mobile; removing a managed app also deletes its app-container data. Before issuing the task, complete the iPhone/iPad data-loss preflight: establish which data is needed, what export or backup is permitted, and an approved, verified recovery path. If management status or data backup and recovery remain unresolved, do not schedule or transfer the removal task.

For Uninstall app, select the target app under Select source > Apps. The list includes apps added to Sophos Mobile or installed on any managed device, but not system apps. Apps not listed are addressed through Identifier and their bundle ID. The task help describes removal as silent, without confirmation on the device; this is not a universal guarantee for every management mode. The general documentation for managed iOS/iPadOS apps explicitly describes this behavior for supervised devices. Before the authorized change, establish the actual management and supervision status and expected confirmation behavior; assume neither universal silence nor universal prompting on non-supervised devices. Check the app target and authorization before retransfer as well; any device confirmation does not replace change authorization. The list restriction does not establish an alternative route for removing system apps.

macOS: installation and license removal are different tasks

Under Install app, select an app from the available list; installation is silent when transferred. If a PKG file contains multiple apps, all of them are installed. Before approval, check the package contents, not just the displayed app name. Even so, Successful initially establishes only that the download has started; installation verification is described below.

Under Unassign VPP app, select the target app from the list of available Apple Business apps. The task removes an assigned Apple Business app license from the device; the user may still use the app for another 30 days. Check the specific app and license assignment for each Mac before running the task, and do not mistake continued app use for a retained license.

Windows: a list entry does not establish eligibility for removal

Under Install app, select an app from the list of available apps; it installs silently when transferred and updates an already installed app. Under Uninstall app, also select the target app from the list of available apps; the older task list describes removal as silent. The newer general Apps uninstallation instructions, however, make silent removal on Windows conditional on the /quiet installation option configured for the app. This does not establish that the bundle task bypasses that condition or behaves identically in every tenant. Before assuming unattended removal, check the specific app’s documented installation options and actual tenant/mode behavior within the authorized change; do not blindly add /quiet to an unknown installer. The uninstall list includes apps added to Sophos Mobile and apps on any managed Windows computer, but not Windows system apps. Only apps installed by Sophos Mobile can be removed; the task fails for an app installed by the user. Before transfer or retry, separately check why the app is listed, how it was installed, and whether the target is authorized.

Do not infer these app tasks of the full Mobile edition from the Threat Defense task lists.

iOS/iPadOS: profiles, SMC connection, and OS updates

For Install provisioning profile, select an app provisioning profile from the available list; it is installed silently when transferred. If the profile is missing, first prepare and complete the app provisioning profile import. Before removal, also review the effects on apps and data described there and complete the checks under Pilot checks and rollback.

Under Uninstall provisioning profile, select the profile using Select source > Profiles. The list includes added profiles and profiles installed on any managed device. Address a profile not listed through Identifier and its profile identifier. Removal is also silent. Both tasks are unavailable under User Enrollment; profile identity and the target device must still be checked before removal.

Reconfigure SMC app reconnects Sophos Mobile Control to Sophos Mobile after accidental uninstallation. The user must scan a QR code or manually enter the configuration details. Administrators can find these details under Show device > Tasks, using the Show icon for the relevant task. Sophos recommends placing Install app for Sophos Mobile Control before Reconfigure SMC app in the bundle so that the app is available. Reconfiguration is unavailable under User Enrollment; it is not a general synchronization fix.

Install latest iOS update applies only to supervised devices or Apple Business devices and is unavailable for User Enrollment; the task fails on other devices. Different updates may be installed depending on the device model. For acceptance, check the result for each model rather than assuming a single version number across the bundle.

ChromeOS and messages

The full Sophos Mobile manual lists Enroll, Assign policy, Send message, and Unenroll for ChromeOS bundles. This specific list contains neither Wipe nor an app installation task; do not infer a general statement about other action interfaces or availability in your own tenant.

Send message on Android, iOS/iPadOS, and ChromeOS accepts plain text. When transferred, the message text appears in a notification window. On Android and iOS/iPadOS, users can view earlier messages in Sophos Intercept X for Mobile in the Threat Defense edition, or in Sophos Mobile Control in the full Mobile edition. On ChromeOS, they remain available in the Sophos Chrome Security extension. A sent message is neither a read receipt nor evidence that a policy has been applied.

Message in an enrollment bundle: The Known Issues list checked on October 6, 2026 identifies SMCSRV-13893, a possible failure of Send message within an enrollment task bundle: if the device takes too long to send APNS/FCM information to the backend, the message task may fail because that information is missing. The entry specifies no exact affected version or fix version and currently lists no workaround. This does not mean every message or the entire enrollment fails. For this failure, first check the actual enrollment and task status, and clarify the specific symptoms with Sophos Support instead of retransferring the entire bundle. Both notices are limited to the stated documentation snapshot and respective failure scenario; before later use, check the current Known Issues list for your version.

Transfer and observable results

Before transfer, check individual devices or device groups, including their current membership and the operating window. The documented transfer workflow names Android and iOS & iPadOS:

1. Under Task bundles > Android or iOS & iPadOS, open the bundle triangle and select Transfer.
2. In device selection, select individual devices or open Select device groups and select one or more device groups on the group selection page. Check current members against the approved target set, then select Next.
3. Select Now for immediate execution, or select Date and enter the execution date and time. Check these settings against the operating window before selecting Finish.
4. Complete the process with Finish. The bundle is transferred to the selected devices at the specified time; this does not yet establish its effect.

Do not claim that the guide establishes the same menu sequence for Mac/Windows/ChromeOS; check platform-specific availability separately.

Task status ≠ device outcome: An Android Enterprise Google Play installation appears successful as soon as the request has been sent to Google, not only after installation has been verified. According to Sophos, Successful on a macOS app task initially means that the download has started; synchronize the device and check installed apps in the device details to verify installation. Check a policy and its effect separately as well; a skipped, unsupported task is not successful execution.

For Android app acceptance checks, inspect the specific target device under Show device > Installed apps and verify actual installation on the device. On Android Enterprise, Apps pending installation shows Installation request to be sent to Google or Installation request sent to Google; after Google installs the app, the entry moves to Installed apps. If the first state persists, check the app’s availability for the country and device type; if the second persists, check Pending downloads in Google Play on the device for a blocking request. Your installation starts only after the downloads listed above it. This status description comes from the direct Play installation workflow and does not establish additional bundle status names. If privacy settings hide Installed apps, the missing view is not evidence that installation is missing; involve an authorized device check or the app owner without changing the privacy setting as a diagnostic test.

Investigate failures; do not blindly rerun the entire bundle

Under Tasks, read the status and Task details for each target device: record timestamps, error codes, and, where available, Details for individual commands. Delayed waits for other tasks; Not started denotes a bundle step not yet processed, Skipped a step unsupported on the device, and Task partly failed commands that were only partly successful.

According to the status table, Will be retried concerns connection problems with third-party servers; Sophos retries every three minutes and marks the task failed after five attempts (15 minutes in total). Failed (retry queued) and Task failed are not the same; Completely failed cannot be retried. With Waiting for user interaction, the task fails after 72 hours without a user response; with Device is locked, it waits for the iOS device to be unlocked and fails after 72 hours if it remains locked. Separately, the confirmation under Commands sent and the success report under Result evaluation started each have a 15-minute limit. These status descriptions are documented product semantics, not evidence of testing in your own tenant.

Before any manual retry, establish for each device which steps have already taken effect and which are still being retried automatically. Investigate and fix the cause in the failed step. The official guides reviewed do not establish automatic rollback of every task in a bundle; do not retry Unenroll/Wipe as a diagnostic step.

Perform the appropriate preflight check for the affected task. For policies, check the policy type and management mode rather than treating Uninstall policy as a generic reversal. Do not inadvertently replace existing Mac/Windows policies. For Android/iOS apps and Windows Install app, check the app version and update approval so that already installed apps are not unintentionally updated. Account for uninstalled apps and removed profiles when deciding whether to transfer again. On Macs, inspect the VPP license assignment rather than merely whether the app remains usable. Permit iOS/iPadOS app removal only for an authorized target and check management/supervision status and expected confirmation behavior within the limits described above.

Deliberately schedule only a separately approved step that is safe to rerun. For Unenroll, explicitly reauthorize removal and the re-enrollment path for each target device; do not expect user confirmation. After execution, verify device status and the actual effect separately.

Further task and synchronization troubleshooting belongs to the separate monitoring workflow.