This article explains how to use the Manage blocklist workflow from the Device Management → Applications (Software) page to block Shadow IT applications and domains across your devices and device groups.
This is part of the consolidated Shadow IT blocking experience in the Swif Admin Console.
What you can do from the Software page
From Device Management → Applications, the Manage blocklist flow lets you:
Block applications (from the Swif catalog or as custom names)
Block domains (manually or via file upload)
Target specific devices and device groups
Apply blocking across supported OS platforms
See a unified blocklist for that application, including block type and policy details
This flow is designed to behave consistently with other entry points (such as Device Details and Device Groups). The key difference here is that:
When you open the modal from a specific application on the Software page,
the application is pre-selected and cannot be changed in that instance of the modal.
Launching “Manage blocklist” from the Software page
In the Swif Admin Console, go to
Device Management → Applications.In the Applications (Software) table, find the app you want to manage.
Click Manage blocklist for that app.
The Manage blocklist modal opens with:
The application pre-selected and disabled (you cannot change the app in this flow).
All other controls (devices, groups, block types, domains) available and enabled.
This lets you quickly manage block policies for one specific application from the Software page.
Choosing how you want to block
Inside the modal, you can configure what you are blocking:
1. Block by application
Select from known apps
Uses the Swif app catalog.
From the Software page modal, the chosen app is already fixed, so this selection is implicitly set.
Enter Custom Application Name
Allows you to block by a string name that may or may not exist in the catalog.
Useful for Shadow IT or custom/line-of-business apps.
2. Block by domain
Enter Domain
Manually enter one or more domains (for example,
example.com).
Upload file
Upload a file containing many domains at once.
The UI shows the file name and number of domains rather than listing all for large uploads.
The blocklist can include both applications and domains. Both will be shown in the resulting blocklist view with appropriate types and labels.
Selecting devices and device groups
You can apply the blocklist to:
Individual devices, and/or
Device groups (including smart groups and any custom-named groups)
Behavior:
The device and device group selection dropdowns show all eligible, enrolled devices and groups.
Device group names are fully flexible; any label you have defined appears as-is in the selector.
Counts of blocked devices and blocked device groups are updated when you save changes and are reflected back in:
The blocklist modal
The Software page summary for that app
If you notice a mismatch between what you selected and the counts shown, it indicates a configuration issue and should be treated as a defect, not intended behavior.
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.
Entering custom app names and domains
Unified placeholder behavior
For free-text inputs where you can type either an app name or a domain, Swif uses a clear placeholder:
Type an Application Name / Domain and Press Enter
Behavior:
Type a value in the field.
Press Enter to confirm and add it to the list.
This applies to:
Enter Custom Application Name
Enter Domain (for domain-based blocking)
Custom application name input behavior
When you choose Enter Custom Application Name:
You see a plain input box, not an open dropdown.
The application catalog dropdown:
Does not open by default.
Appears only after you start typing and only when there are catalog matches.
You can:
Select one of the suggested catalog apps, or
Continue using your own string and treat it as a purely custom app name.
This avoids confusion with Select from known apps and makes it clear that the field supports both free text and assistive suggestions.
Domain blocking: manual vs file upload (web filtering)
You can block domains associated with the application directly from this flow.
Entering domains manually
Select Domain → Enter Domain.
Type a domain (for example,
example.com).Press Enter to add it.
Repeat for additional domains.
When Enter Domain is active, file upload options are hidden to keep the UI focused.
Uploading a file of domains
Select Domain → Upload file.
Upload a CSV or other supported file containing domains.
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.
To make it obvious that manual entry and file upload are alternatives, the modal includes an “OR” spacer between the upload section and any pre-loaded file selection components.
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 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.
Blocklist display on the Software page
After you save your blocklist changes:
Return to Device Management → Applications.
In the application’s row, a blocklist table / section presents all configured blocks.
You’ll see:
Blocked item type
Application Name (string input used as identifier)
Domain
Target scope
Devices and/or device groups affected
Block type / Policy usage
A policy name, which is a clickable link to that policy.
Domains from file uploads
Shown by file name and domain count.
Large domain lists are not expanded inline.
Rule types chip
A small chip shows how many rule types the policy contains.
Hovering over the chip displays a tooltip with details of those rule types.
Both app-based and domain-based blocks are visible side-by-side, so you can see everything that applies to that app in one place.
Bulk blocklist actions
From the Software page, you can also:
Select multiple applications.
Apply bulk blocklist actions via the Manage blocklist flow.
Behavior:
All selected apps are processed.
Each app’s resulting block entries appear in the blocklist table for that app.
The underlying OS, device/group selection, and path/domain rules apply per app.
Behavior expectations and consistency
The consolidated Manage blocklist flow is designed to be:
Consistent across entry points
Whether you open it from:Device Management → Applications (Software page),
Device Details,
Device Groups,
the workflow, validations, and options behave the same, except for:
Pre-selection context (which app/device/group is locked in).
Fully enabled
Options inside the modal are not disabled just because something is pre-selected:From the Software page, the application field is the only locked element.
You can still:
Add domains,
Adjust devices/device groups,
Mix app and domain blocks,
Configure OS targets.
If you see options that appear disabled (other than the pre-selected application field in this flow), that should be treated as an issue to report.



