Skip to main content

Shadow IT – Block Applications from the Device Group page

This article explains how to use the Manage blocklist workflow from the Device Group page to block Shadow IT applications and domains across your fleet. It also calls out important OS‑specific behavior (especially for Windows) and how block entries are displayed.

This feature is part of the consolidated blocking experience for Shadow IT in the Swif.ai web app.


What you can do from a Device Group

From a device group, you can:

  • Block applications (by known app catalog entry or custom app name)

  • Block domains (typed manually or uploaded via file or category)

  • Target specific OS platforms the app supports

  • See a consolidated view of all block entries that apply to that device group

The key difference versus other blocklist flows is that, on the Device Group page:

  • The device group context is locked (pre‑selected and cannot be changed)

  • When launched from a specific application row, the application is pre‑selected and cannot be changed in that modal


Launching “Manage blocklist” from a Device Group

  1. Go to Device Management → Device Groups in Swif.

  2. Open a device group.

  3. On the Applications table within that device group:

    • Select an application, then

    • Click Manage blocklist.

The Manage blocklist modal opens with:

  • The device group pre‑selected (not editable)

  • If launched from an app row, the application pre‑selected and disabled, so you can’t accidentally change it


Choosing what to block

Inside the Manage blocklist modal, you can choose between:

  1. Applications

    • Select from known apps (Swif catalog)

    • Enter custom application name (manual entry)

  2. Domains

    • Enter domain (manual)

    • Upload file (for many domains at once)

    • Category (bulk category domains at once)


OS‑specific behavior for desktop app blocking

Swif's backend uses different technologies per operating system (e.g., Santa for macOS, AppLocker for Windows, the Swif Agent for Linux, and a manifest‑based uninstall flow for Android). The UI abstracts this, but there are a few important OS‑specific details.

Mac

For macOS devices, Swif can block applications by name matching and other app attributes. When you block an app for macOS:

  • You can simply provide the application name (or select one from the catalog).

  • Swif creates or updates an Application Block Policy that prevents the app from running on targeted macOS devices.

Linux

For Linux devices, Swif blocks applications by application name:

  • Provide the app name string (or select it).

  • Swif creates or updates a Linux Application Block Policy.

Windows – path‑based blocking

For Windows devices, application blocking relies on file path information because it uses Windows AppLocker under the hood.

When you include any Windows devices in the target:

  • The Manage blocklist modal will ask you for an Application path (appPath).

  • A Windows‑specific placeholder is shown, e.g.:

    • C:\Program Files\Teamviewer
  • If you try to save without a path, you'll see an error message:

    • "Application path is required for Windows"

Internally, Swif uses this path to create or update a Windows AppLocker Policy across multiple rule collections (e.g., .exe, .appx, .msi).

Note: Some critical Windows applications (for example, certain Microsoft apps like Edge) may not be fully enforceable due to OS limitations. Always test your policy against a small set of devices first.

Android – package‑based blocking

For Android devices, application blocking uses the app's Android package identifier (e.g., com.company.app) rather than a display name or file path.

When you include any Android devices in the target:

  • Known apps — If you select an app from Swif's Applications Catalog, Swif automatically resolves the correct Android package ID. No additional input is required.

  • Custom apps — If you use the "Enter Custom Application Name" option, provide the Android package name (e.g., com.example.myapp).

  • No installation path is needed for Android — only the package identifier.

Under the hood, Swif adds the app to the device‑level uninstall manifest rather than creating a separate MDM policy. The backend computes the effective uninstall list per device at manifest‑update time, merging any blocked‑app overrides with baseline app settings.

Note: If an app does not have a known package identifier in Swif's catalog, the package ID will not be resolved automatically. In that case, use the custom entry option and provide the package name directly.


Special behavior for Windows app blocking (appPath requirement)

For Windows devices, blocking is enforced via app blocker policies and requires the application path.

When the device group includes Windows

If your Target OS includes Windows (for example, you select All, or specifically Windows):

  • You will see an Application path (or similar) input.

  • The placeholder text will indicate a Windows path format (for example, C:\Program Files\App\app.exe).

  • This field is required. If you don’t provide it, you’ll see an error:

“Application path is required for Windows”

and you won’t be able to proceed.

When the device group is macOS / Linux only

If you’re targeting macOS and/or Linux only:

  • The application can be blocked by app name.

  • No appPath is required.


Desktop app blocking: Entering custom app names and domains

Placeholder behavior

Where you can type a value directly (for both app names and domains), the placeholder text is:

Type an Application Name / Domain and press Enter

Behavior:

  • Type your custom application name or domain.

  • Press Enter to add it to the queue.

  • This helps clarify that typing alone is not enough; pressing Enter confirms the entry.

“Enter Custom Application Name” interactions

When you choose Enter Custom Application Name:

  • You get a plain input box instead of an immediate dropdown.

  • The known app dropdown is not opened by default.

  • As you type, if there are matches in the application catalog:

    • Those are suggested in a dropdown.

    • You can select one of the matches, or just continue with your manual string.

  • This avoids confusion with the Select from known apps option and makes it clear that this field:

    • Accepts free‑text values, and

    • Optionally helps you find catalog entries if they exist.


Domain blocking: manual / file upload / category (web filtering)

You can block domains associated with the application directly from this flow.

Entering domains manually

  1. Select Domain → Enter Domain.

  2. Type a domain (for example, example.com).

  3. Press Enter to add it.

  4. Repeat for additional domains.

Uploading a file of domains

  1. Select Domain → Upload file.

  2. Upload a CSV or other supported file containing domains.

  3. The blocklist UI will:

    • Display the uploaded file name.

    • Show the total count of domains in the file.

    • Avoid listing every individual domain in the UI if you have thousands of entries.

"Block sign‑up” control

When you open Manage Blocklist from a Shadow IT app, Swif now supports an app‑level Block sign‑up control:

  • A toggle such as Block sign‑up for this app appears in the app‑level blocking area.

  • This blocklist control is scoped to the domains you uploaded, not the entire team or tenant. The blocklist can then be assigned to devices or groups to be effective.

  • When enabled:

    • New sign‑ups to those specific domains are blocked according to Swif’s standard enforcement (for example, via the browser extension on managed devices).

  • When disabled:

    • Sign‑up behavior control will be removed.

Select from Categories (category-based domain blocking)

In addition to entering domains manually or uploading a file, you can now block entire categories of domains at once. This is ideal for organizations that need to enforce compliance standards (e.g., ISO, SOC2) without manually entering thousands of individual domains.

How it works

When you choose Application Domain in the Manage Blocklist modal:

  1. Set the Domain Selection mode to "Select from Categories."

  2. Swif loads a list of pre-populated domain categories from the backend, each with a domain count.

  3. Select one or more categories using the checkboxes.

  4. Click "+ Add to Blocklist Queue" to add the selected categories to your queue. A success toast confirms the addition.

  5. Proceed to Step 2: Device Selection to assign the category block to specific devices or device groups.

  6. Click Continue to save.

Category

Description

Advertising

Ad-serving and tracking domains

AI

AI tool and service domains

Core

Core infrastructure blocklist domains

FireBog

Community-maintained blocklist domains

NRDs

Newly Registered Domains

Porn

Adult content domains

Social Media

Social networking platform domains

Telemetry

Telemetry and analytics collection domains

Block Sign-Up Only with categories

The "Block Sign-Up Only" toggle is also available when using category selection. When enabled, Swif allows website access but prevents the user from signing up or logging into web apps within the blocked categories.

How category blocks appear in Device Details

Once saved, category blocks appear in the Device Details → Apps → Blocked tab with:

  • Category name (e.g., "AI")

  • Domain count (e.g., "18 domain(s)")

  • Block Type badge showing "Category" — distinguishing them from per-domain or file-upload blocks

Removing category blocks

  • To remove a single category block, click Allow on the category row in the Blocked list.

  • To remove all blocks (including both category and per-domain entries), use "Allow All."

Notes

  • Category and per-domain blocks can coexist on the same device — they are displayed with different Block Type badges for clarity.

  • Subdomains within a category are automatically covered with wildcard rules.


Reviewing the blocklist for a Device Group

After you complete the steps and save:

  • The blocked items appear in the blocklist table associated with the device group.

  • For each block entry, you’ll see:

    • Type:

      • Application Name

      • Domain

    • Target OS (for app blocking)

    • For Windows entries: the Application path you configured

    • Policy / Block type information

    • Status

When domains were added via file upload:

  • The table shows:

    • The file name.

    • The number of domains in that file.

  • This keeps the UI usable even for thousands of domains.


Viewing blocklist details on an individual device

From Device details → Applications:

  • You can review how block policies apply to that specific device.

  • For each blocked item, the UI shows:

  1. Application Name

    • The string that was used as the app identifier (for custom names, this is exactly what the admin typed).

  2. Block type / Usage (via policy name)

    • The policy name is displayed and acts as a link to that specific policy.

    • This lets you quickly jump from device‑level view into policy configuration.

  3. Rule types tooltip

    • A chip / badge indicates how many rule types the policy has.

    • Hovering over it shows a tooltip with more detail.

  4. Domain file entries

    • As with device groups, file‑based domain entries show:

      • The file name.

      • Domain count (not an inline list of all domains).


Behavioral notes and troubleshooting

  • Device list and device groups dropdowns inside this flow may be disabled by design when the context is already fixed (for example, when launched from a specific device group).

  • If a blocked app does not appear in the blocklist or on the device:

    • After this consolidated blocking work, a policy not being assigned is considered a bug, not a “MDM delay” by design.

    • Confirm the Target OS and, for Windows, that a valid appPath was provided.

Did this answer your question?