This article explains the key capabilities of the Shadow IT → Manage Blocklist experience in Swif, based on the consolidated blocking flow introduced in the “Shadow IT – Manage Blocklist” update.
Use this when you want to quickly block risky applications or domains discovered in Shadow IT across specific devices or device groups.
1. Launching the Manage Blocklist modal
From the Shadow IT report or Device Details → Applications:
Select an application.
Click Manage Blocklist.
What happens:
The Manage Blocklist modal opens with:
The selected application pre‑filled.
Application name and primary domain pre‑filled when coming from Shadow IT (e.g., selecting TeamViewer pre-fills
TeamViewerandteamviewer.com).
You can still adjust other options (devices, device groups, domains, etc.) and add multiple entries to a blocklist queue.
2. 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.
3. Desktop app blocking: Known apps vs Custom app
The Manage Blocklist modal supports two ways of specifying apps:
Select from Known Apps
Use this when the app exists in Swif’s Applications Catalog.
As you type, you’ll see matching apps.
This is typically what you get when starting from a Shadow IT entry.
Enter Custom Application Name
Use this when the app is not in the catalog.
You see a simple input box (not an always-open dropdown).
Placeholder / guidance text:
“Type an Application Name / Domain and Press Enter”
The dropdown only appears after you type and there is a match, avoiding confusion with the known app selector.
Smart hide/show behavior
To keep the UI focused and reduce clutter:
When Select from Known Apps is chosen:
The custom application name input is hidden.
When Enter Custom Application Name is chosen:
The known-app dropdown is hidden.
Only one input method is visible at a time, making it clear which mode you’re using.
4. Domain blocking: manual / file upload / category (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.
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.
"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:
Set the Domain Selection mode to "Select from Categories."
Swif loads a list of pre-populated domain categories from the backend, each with a domain count.
Select one or more categories using the checkboxes.
Click "+ Add to Blocklist Queue" to add the selected categories to your queue. A success toast confirms the addition.
Proceed to Step 2: Device Selection to assign the category block to specific devices or device groups.
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.
5. Device and device group selection
You can target your blocklist to:
Specific devices
Specific device groups
(Depending on your setup) all devices matching your criteria
Key behaviors:
The device selection dropdown includes all enrolled devices (per QA scenarios).
Device groups can be created/selected with arbitrary names, which are displayed correctly.
Bulk selection is supported for quickly applying policies across many endpoints.
6. Blocklist queue and bulk actions
As you configure blocks, entries are added to a blocklist queue in the modal.
Capabilities:
Add multiple apps and domains before saving:
e.g., block an app by name on macOS and by path on Windows, plus relevant domains.
Perform bulk actions:
Select multiple apps/domains and apply blocking in one go.
The queue reflects:
App name or domain
Target OS and devices/device groups
Path (for Windows app blocking)
Block type (app name vs domain, etc.)
7. Blocklist display on Device Details → Applications
After saving, you can see how blocklists apply at the device level in Device Details → Applications.
How domain entries are shown
For domains added via file upload:
The UI shows the file name and a count of domains.
Individual domains are not all listed when there are large numbers, to keep the view readable.
Policy block type and usage
Each block entry includes:
Application Name
The string you typed or selected as the app name.Block Type
Indicates how the block is applied (by app name, domain, etc.), and:Shows usage via Policy Name.
The policy name is a link to the specific policy, so you can jump directly to it.
Rule type chip and tooltip
In blocklist/usage tables:
A chip shows how many rule types (e.g., app, domain, OS variants) a policy has.
Hovering over the chip opens a tooltip with rule-type details.
This gives quick insight into how broad or granular a policy is without having to open it.
8. Consistent behavior across entry points
The Manage Blocklist flow is designed to behave the same from multiple starting points:
From Shadow IT → Manage Blocklist
From Device Details → Applications → Manage Blocklist
In all entry points:
The modal layout and steps are consistent.
The pre-selection reflects your context (e.g., app from Shadow IT vs app on a specific device).
All features described above (OS handling, known/custom app, domains, bulk actions, tooltips) work in the same way.