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)
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
Go to Device Management → Device Groups in Swif.
Open a device group.
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:
Applications
Select from known apps (Swif catalog)
Enter custom application name (manual entry)
Domains
Enter domain (manual)
Upload file (for many domains at once)
To keep the UI focused, Swif hides irrelevant options based on your selection:
When you select Select from known apps, the custom app name input is hidden.
When you select Enter custom application name, the known app dropdown is hidden.
When you select Domain → Enter domain, the file upload options are hidden.
When you select Domain → Upload file, the manual domain input is hidden.
OS‑specific behavior for application 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.
macOS
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
appPathis required.
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.
Adding domains via manual input or file (web filtering)
You can block domains in two ways:
Enter domain
Type a domain (for example,
example.com).Press Enter to add it.
Repeat for additional domains.
Upload file
Upload a CSV or supported file with many domains.
To prevent UI overload, the blocklist display will:
Show the file name.
Show the count of domains in that file.
It does not list every individual domain for very large files.
To make the choice clear, the UI includes an “OR” spacer between:
Upload file, and
Select from pre‑loaded file (if applicable),
so it’s obvious these are alternative paths.
Per‑application “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 group level, 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.
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:
Application Name
The string that was used as the app identifier (for custom names, this is exactly what the admin typed).
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.
Rule types tooltip
A chip / badge indicates how many rule types the policy has.
Hovering over it shows a tooltip with more detail.
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
appPathwas provided.