Changelog

We’ve updated Device Management to make it obvious when a policy does not apply to BYOD devices and to prevent misconfiguration:

• Policy creation

  • When creating a policy that doesn’t support BYOD, BYOD devices are now disabled in device pickers.

  • In the Select device groups step, if a group contains BYOD devices, we show an attention box explaining that the policy won’t apply to those BYOD devices.

  • The “No. of devices” column has been renamed to “Devices” and now shows a clear breakdown of org‑owned vs BYOD device counts.

• Policy details

  • In the Devices tab, BYOD devices are disabled in the Add devices modal for BYOD‑incompatible policies.

  • When BYOD devices are attached to a BYOD‑incompatible policy, we show:

    • An attention box explaining that the policy can’t be applied to BYOD devices.

    • An inline warning status next to each affected BYOD device.

  • In the Device groups tab (and Add Device Groups modal), if groups contain BYOD devices, we display an attention box that the policy does not apply to BYOD devices in those groups.

• Device groups

  • When creating a device group, selecting a BYOD‑incompatible policy now surfaces an attention box so admins understand those policies won’t affect BYOD devices in the group.

  • In Device Group details → Policies, we show an attention box whenever a group with BYOD devices has BYOD‑incompatible policies assigned.

These changes reduce the risk of silently misconfigured BYOD setups while keeping org‑owned devices fully supported.

We’ve added a dedicated configuration experience in the Swif admin web app for Temporary Admin Elevation.

What’s new

• New settings page at Settings → Local Account Controls → Temporary Admin Access with:

  • An intro/empty state when the feature hasn’t been configured yet

  • A clear “configured” state once you’ve saved a policy

• Configuration modal for Temporary Admin Elevation that lets admins:

  • Enable or disable Temporary Admin Access

  • Choose scope: All devices or Selected device groups (with a “Choose device groups” selector)

  • Select allowed OSes (macOS, Windows, Linux)

  • Set guardrails:

    • Max elevation duration per session (e.g., 15 / 30 / 60 / 120 minutes)

    • Max sessions per user per day (and/or week)

    • Cooldown time between elevation sessions

• Validation, loading, and error handling

  • Required fields and numeric ranges are validated client‑side

  • The Save button stays disabled until inputs are valid

  • Loading spinners and inline/toast error messages are shown when fetching or saving config

• Post‑configuration summary

  • After saving, the main panel shows:

    • Whether Temporary Admin Access is enabled

    • Scope summary (all devices vs selected groups)

    • Current limits (session duration, sessions per day/week, cooldown)

    • Supported OSes

  • Admins can quickly re‑open the modal to edit or turn the feature off, which returns the page to the intro state

Device users can request elevation at the Swif desktop app:

You can read more about how the feature works end‑to‑end in our help article:
Temporary Admin Elevation | Help Center | Swif.ai

We’ve streamlined how you launch COMP (self‑hosted GRC software) from the Compliance Marketplace.

What changed

• For organizations that already have a comp.swif.ai account linked to Swif:

  • One‑click launch: Clicking Launch COMP now opens https://comp.swif.ai directly whenever possible.

  • No more API key popup when a cached Swif API token is available – Swif uses the cached token to authenticate you automatically.

  • If no cached token is available, Swif skips the old API‑key popup and sends you straight to the COMP login page instead.

• For organizations that don’t have a COMP account yet:

  • The existing onboarding popup (showing your Swif API key, Copy button, and Launch COMP button) continues to work exactly as before.

Where this applies

This improved behavior applies to both launch entry points in the Compliance Marketplace:

• The banner (Compliance → Compliance Marketplace → Launch COMP)

• The COMP card in the Marketplace grid (Launch button)

Both now share the same, simplified launch logic.

Result

• Existing COMP customers get a faster, one‑click launch with fewer prompts.

• New COMP customers keep the current, guided onboarding with no behavioral changes.

You can find the full product help article here:
Compliance Marketplace – Self-hosted GRC software - COMP | Help Center | Swif.ai

Help article: Manually re-sync device compliance evidence to Drata, Vanta, and Thoropass | Help Center | Swif.ai

We’ve added a bulk Sync Compliance / Bulk Sync action in the Device Management → Devices list view so you can re‑sync compliance evidence for many devices in one shot.

What’s new

• New Bulk Sync action in the Devices list (row‑checkbox selection).

• Supports Drata, Vanta, Thoropass, and Google in a single flow.

• Confirmation modal shows:

  • Which integrations will be used.

  • Exactly which evidence types will be synced for each integration.

• Async bulk job:

  • Starts a background sync for all selected devices.

  • Shows in‑progress and completion states.

• Per‑device outcomes:

  • Devices can complete as success, failed, or ineligible without blocking others.

  • Unenrolled devices or devices without an owner are automatically excluded.

This update is especially useful if sync has fallen behind for many devices and you previously had to open each one and click Sync individually.

You can now connect a Git repository and run commands from it directly on Mac and Windows devices.

This feature works with any build or run script in your repo, including:

• Go (go run, go build, custom Go scripts)

• Python (python / pip-based scripts)

• Node.js (npm, pnpm, yarn scripts)

• Other custom shell or batch scripts

Point Swif to the repo and the command you want to run, and we’ll take care of executing it on the selected devices. This gives you a flexible way to reuse your existing automation—whether that’s a Makefile target, a Go tool, a Python script, or a Node CLI—without changing how your repo is structured.

What’s new

1. New execution types in Command creation

When you go to Commands → Create new command, Step 1 is now organized into:

• Basic Information

• Execution Type

• Execution Settings

Under Execution Type, you’ll now see:

1. Run by Command Script (existing behavior, unchanged)

   • Same custom script flow you used before.

   • Now includes a Run Security Risk Analysis action in the UI.

2. Run by File (new)

   • Paste or upload a single script file (e.g. .py, .js, .go, .sh) and run it directly.

   • Filename and File content are required; you can’t proceed without both.

   • For this mode:

     • Run Schedule, Command status, and Webhook configuration are hidden to keep it focused on ad‑hoc runs.

   • Includes an inline Security Risk Analysis notice.

   • Review step shows a dedicated Run by File summary.

3. Run by Git Repo (new)

   • Connect a Git repository and run commands via a build script target (Makefile, Go, Python, Node, and more).

   • You configure:

     • Repository URL

     • Branch

     • Path: If your build script is not at the repo root, specify the path (e.g. ./scripts/deploy).

     • Repo Name

     • Build Script

   • Repo URL and Build script are required fields

   • For this mode:

     • Run Schedule, Command status, and Webhook configuration are hidden.

   • The review step clearly summarizes:

     • Repo URL

     • Branch

     • Build script

     • Any platform‑specific execution settings

Full user help is available here:
Run Commands by Script, OSQuery, File, or Git Repo | Help Center | Swif.ai

2. Cross‑platform support (Mac, Windows, Linux)

By Git repo + By File commands are now supported from the Web App for:

• Mac

• Windows

• Linux

For all three platforms:

• You can create a command that:

  • Uses a Git repo as the script source.

  • Uses the build script as defined in the underlying backend work.

• The UX and field set are consistent across OSes, with platform‑specific nuances (paths, shells, prerequisites) reflected in helper text or copy where relevant.

• A prior issue where template‑based commands did not correctly create Mac variants has been fixed; templates that show all three OS configurations now create commands for Mac, Windows, and Linux as expected.

3. Execution, status, and error handling

When you execute a Git‑backed command from the Web App:

• Swif dispatches the run via the build script for the selected platform(s).

• The existing command/job detail view shows:

  • Normal status progression (queued → running → succeeded / failed)

  • Logs and output from the run

• Git / build script specific errors (e.g. bad repo URL, missing branch, or build script not found) are surfaced as clear, user‑friendly messages, rather than opaque generic failures.

Learn more at Run Commands by Script, OSQuery, File, or Git Repo.

We’ve added support for triggering custom command scripts in Swif.ai via webhooks. This makes it easier to plug Swif.ai into your existing automation (CI/CD, IT workflows, security tools, etc.) without needing an admin in the console.

What’s new

• Webhook-triggered commands

  • When creating or editing a command, you can enable a Webhook configuration section.

  • For each command with webhook enabled, Swif.ai now exposes a webhook URL of the form:

    • https://mdm.swifteam.com/api/v1/agent/command/webhook/:commandId

  • The command can still be run manually or run on schedule; webhook is an additional trigger option, not a new run type.

• Command tokens (Growth plan+)

  • You can now generate one or more tokens for each command.

  • Tokens are managed in Command Details → Tokens:

    • Create and delete tokens (CRUD).

    • See token metadata.

    • Use a Copy button next to each token so admins can safely copy values when needed.

  • Tokens are required to trigger a command via webhook and are scoped to the command’s team.

• Triggering commands by device

  • The webhook trigger accepts device lists by mdmDeviceId (not serial number) for reliability across Windows, macOS, and Linux.

  • Payload format:

    { "deviceIDs": [ "mdmDeviceId-1", "mdmDeviceId-2" ] }

• MDM APIs for token management

  • Create Command Token

    POST /api/v1/agent/command/token

  • List Command Tokens

    POST /api/v1/agent/command/token/list

  • Delete Command Tokens

    DELETE /api/v1/agent/command/token

  • All token APIs are protected by Authorization and team-id headers, and only admins with valid credentials can create, list, or delete tokens.

• Security & access control

  • Webhook requests must include a valid command token in the header; otherwise, the request is rejected, and the command is not executed.

  • Token APIs enforce:

    • Admin-only access for creation/deletion.

    • Proper team scoping via team-id.

    • 4xx responses (401/403/404) for invalid/missing auth or cross-team access, without leaking sensitive details.

Plan & availability

• Webhook-triggered commands and command token management are available for Growth plan and above.

• For full examples and implementation details, see:

  • Updated webhook usage section: Run a Command Script | Help Center | Swif.ai

If you’d like, I can also draft a shorter “What’s new” version tailored for in-app changelog or release notes.

We’ve added a new Device Name Auto-Renaming configuration to Smart Device Groups so you can standardize computer names automatically based on assigned users and device attributes.

What’s new

In the Create New Device Group flow (Smart Group) and in Device Group Details → Overview, you can now configure:

1. Device name format

   • Define a custom naming pattern using variables (e.g. user, device model, serial number).

   • Insert variables via clickable chips; they’re added at the cursor position.

   • Hyphens (-) are automatically added between variables for consistent formatting.

   • The format is fully editable (insert, delete, and change order).

2. Rename trigger

   • Choose when Swif should automatically rename devices in the group:

     • On assignment or when joining this group

     • On assignment only

     • When joining this group only

3. If device has no assigned user

   • Define fallback behavior when a device isn’t assigned to a user:

     • Keep current computer name

     • Use group name + serial number

     • Use device model + serial number

4. Duplicate name handling

   • Add unique suffix if a duplicate name exists: when enabled, Swif appends a numeric suffix to avoid collisions (e.g. Sales-MacBook-1234-2).

Behavior & data

• The Device Name Auto-Renaming settings are part of the device group’s configuration.

• Values are saved when you create or update the group and are shown read-only in Device Group Details → Overview.

• The UI is wired to the existing create/update Device Group payload and will respect your stored configuration going forward.

• Related help docs:

  • Device Name Auto-Renaming for Smart Groups: Device Name Auto‑Renaming for Smart Groups | Help Center | Swif.ai

  • Creating Smart Device Groups in Swif: Creating Smart Device Groups in Swif | Help Center | Swif.ai

When creating a new policy in Swif, admins can now immediately see which policy types are already in use and quickly inspect existing configurations.

What’s new

• “Existing policies configured” label in Select Policy

  • On the Create New Policy – Select Policy screen, each policy type now shows a label with how many policies of that type already exist, e.g.:

    • 3 existing policies configured

    • 1 existing policy configured

  • The label uses the exact count from backend data.

  • If there are 0 existing policies for a type, the label is hidden to keep the layout clean.

• Tooltip with list of existing policies

  • For any policy type with existing configurations, the info icon now shows a tooltip listing those policies (name and key identifiers).

  • Clicking a policy in the tooltip opens its policy details in a new browser tab, so you don’t lose your place in the Create Policy flow.

• Accessibility & behavior

  • Tooltip is keyboard-focusable and its links are accessible.

  • Links are set to open in a new tab with appropriate attributes/ARIA where needed.

  • Implementation is optimized to avoid performance regressions even for tenants with many existing policies.

Why this matters

This change makes it much easier for admins to:

• Avoid accidentally duplicating policy types that are already configured.

• Reuse or reference existing policy setups by jumping straight to their details from the tooltip.

• Maintain a cleaner, more understandable policy configuration experience as tenants grow.