Changelog

We’ve added a dedicated Okta Verify for Windows app template to make deployment via Swif simpler and more consistent.

What’s new

• Okta Verify for Windows app template

  • Now available under Software → App Templates as Okta Verify for Windows.

  • Discoverable and assignable just like any other app template.

• Windows installer support

  • Upload either the official EXE or MSI installer from your Okta Admin downloads.

  • Both installer types are fully supported in the template flow.

• Desktop MFA guidance is built into the template

  • The Windows template now includes a clear note explaining when advanced Okta Desktop MFA arguments are required:

    Note: The SKU, CLIENTID, CLIENTSECRET, and ORGURL values are only required when Desktop MFA is enabled.
    If you are not enabling Desktop MFA, you may omit or remove these arguments.

  • These arguments are optional unless you are specifically configuring Okta Desktop MFA.

• Platform scoping

  • The Okta Verify for Windows template is scoped to Windows devices only, following existing platform rules.

Learn more

For detailed setup steps and argument examples, see the updated help article:
Okta Verify app installation | Help Center | Swif.ai

We’ve updated the wording for key software enforcement actions in the Application Management installations experience so it better matches how SecureHive actually works and reduces confusion for admins.

What’s changed

• “Install” → “Enforce Install”

  • On the Application Details page, the primary install action is now labeled Enforce Install.

  • The Install Software (All Devices) modal copy (title, body, primary button) now consistently uses Enforce Install language.

• “Uninstall” → “Enforce Removal”

  • On the Uninstall Application flow, the primary uninstall action is now Enforce Removal.

  • The Enforce Removal confirmation modal now:

    • Uses a clear question in the title:
      Remove this app from the device?

    • Clarifies what happens next:
      This application will be uninstalled and moved to the blocklist for this device. If the user reinstalls it, it will be automatically removed until you remove it from the blocklist.

    • Uses Enforce Removal on the primary button.

  • The toast notification after enforcing removal also uses the new Enforce Removal terminology.

• “Disable Force Installation” → “Clear Enforcement”

  • Anywhere you previously saw Disable Force Installation (for devices with a forced install), the action is now labeled Clear Enforcement.

  • The Clear Enforcement confirmation modal and its toast message both use Clear Enforcement consistently.

Behavior (what stays the same)

• Under the hood, all actions behave exactly as before:

  • Enforce Install still enforces installation.

  • Enforce Removal still uninstalls and moves the app to the blocklist for the device.

  • Clear Enforcement still removes the enforced state for that device/app.

• Button placement, hierarchy (primary/secondary/tertiary), and toast behavior are unchanged; only the wording and supporting copy were updated.

We’ve tightened how Swif handles certain high‑impact MDM actions on Windows BYOD (Bring Your Own Device) machines to make limitations clearer and prevent confusing failures.

What changed

For Windows devices marked as BYOD, the following actions are now visibly blocked in the Web App UI:

• Device-level

  • Lock

  • Wipe Data (includes /erase-device and soft-wipe)

  • Rename Device

• Account-level (on the device)

  • Create User Account

  • Reset Password

  • Change Permission Level

  • Lock Account

  • Delete Account

How it works in the UI

When you open a BYOD Windows device:

• These actions remain visible but are disabled (greyed out).

• Hovering them shows a tooltip in the format:
  "[Action] is not supported on BYOD devices"
  (e.g. “Wipe Data is not supported on BYOD devices”).

• No dialogs, confirmation modals, or backend commands are triggered from these controls on BYOD devices.

This matches the existing BYOD limitations documented here:
BYOD Limitation (Apple, Windows) | Help Center | Swif.ai

Why this matters

• Prevents admins from attempting actions that will be rejected by the MDM service for BYOD devices.

• Makes BYOD limitations discoverable directly in the device UI, reducing trial‑and‑error and support tickets.

• Keeps corporate devices fully functional while clearly signaling stricter behavior on employee‑owned Windows devices.

You can now control “Block sign-up” on a per‑application basis for Shadow IT apps directly in the Swif.ai web app.

What’s new

• Added a “Block sign-up for this app” toggle in the Shadow IT → App detail / consolidated blocking view for each Shadow IT application. You can find the same toggle at the consolidated blocking view at Device details, Groups, or the software page.

• The control is scoped at the domains (not global/team), so you can align blocking behavior with the specific risk profile of each domain. The control can then be assigned to devices or groups to be effective.

• Added basic analytics/telemetry for:

  • Viewing the “Block sign-up” control.

  • Toggling it on/off.

Behavior & precedence

• 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.

Docs

• Shadow IT blocklist key features: Shadow IT – Manage Blocklist Key Features | Help Center | Swif.ai

• Block from device details: Shadow IT – Block Applications from Device Details | Help Center | Swif.ai

• Block from device group page: Shadow IT – Block Applications from the Device Group page | Help Center | Swif.ai

• Block from software page: Shadow IT – Block Applications from the Software page | Help Center | Swif.ai

We’ve upgraded the Device Details → Activities tab to make audit and review work much easier:

• New Status column

  • Every activity log now has a clear status: Unreviewed, Reviewed, or Archived.

  • By default, the list shows Unreviewed + Reviewed events so you can focus on what matters now.

• Review workflow actions

  • From each row’s action menu you can:

    • Mark as Reviewed

    • Mark as Unreviewed

    • Archive Log

    • Add Note

  • Reviewed items show a tooltip like: “Reviewed at YYYY-MM-DD by Jane Doe” so you always know who acknowledged an event and when.

• Archiving and dedicated Archived view

  • You can now archive (soft‑delete) log entries you no longer need in the main view.

  • Archived events are hidden from the default list but can be viewed by filtering to Archived status.

  • Archived items are read‑only and clearly indicated in the table, preserving your audit trail without clutter.

• Better filtering and sorting

  • Filter by any combination of Unreviewed / Reviewed / Archived to slice activity history the way you need.

  • Activity logs are sorted by their created date, matching the timestamp shown in the UI, so the timeline is consistent and predictable across edits.

• Refined layout and UX polish

  • The “Performed by” label now appears directly under each activity entry for quicker scanning.

  • Empty, loading, and error states are clarified so it’s obvious whether you’re waiting on data, have nothing to review, or need to retry an action.

To learn how to use these features in detail, see:
Managing Activity Logs and Notes on a Device | Help Center | Swif.ai

We’ve added a new Automated actions experience to geofencing so you can define what should happen when devices enter or leave a geofenced area.

What’s new

• New “Automated actions” step in the Create Geofence flow

  • Appears after the geofence definition steps.

  • Includes a read‑only “Geofence context” panel that shows which locations and devices/device groups the geofence applies to.

• Configurable post‑actions per geofence

  • Add, edit, and delete actions in an Actions list:

    • Notification

    • Lock device

  • Actions are only available when the geofence targets at least one device or device group.

• Default notification, old trigger removed

  • The old “Notification trigger” checkbox has been removed from the Basic configuration step.

  • New geofences now include a default Notification automated action in the Automated actions step, which you can modify or remove.

• Action‑level trigger events

  • Trigger events are configured per action (not at geofence level):

    • Notification: On Entry, On Exit, or On Entry & Exit

    • Lock device: On Entry or On Exit (no combined entry & exit option)

  • You can have only one Notification action per geofence.

  • You can have at most two actions total per geofence (one Notification + one Lock device); once both exist, the Add action button is disabled.

• Add / Edit Action modal

  • A new Add action button opens a modal to configure:

    • Action type (Notification or Lock device)

    • Trigger event

    • Any action‑specific fields (e.g., lock message)

  • The same modal is used for editing existing actions (fields are pre‑populated).

  • Policy assignment has been moved out and is tracked separately (ST‑6965), so it does not appear as an action type.

• Review & View experiences

  • The Create Geofence Review step now includes an Automated actions section summarizing each action (type, trigger event, key details) in a read‑only view.

  • The View Geofence side panel has been extended to show an Automated actions summary, matching existing panel patterns. This view is read‑only—no add/edit/delete from here.

Platform support

• Available for macOS, Windows, and Linux devices, aligned with your existing geofencing and device lock capabilities.

For configuration details and examples, see:
Configure automated actions for geofencing (notifications and device lock) | Help Center | Swif.ai

We’ve redesigned the Shadow IT Insights Dashboard to make AI and Shadow IT activity clearer and easier to understand.

What’s new

• Updated Overview KPIs

  • KPI row now fills the full width with no awkward gaps.

  • Each KPI shows a trend percentage (e.g. +12%, -3%) instead of icons.

  • KPI widgets align with the new 1.0.1 design from our updated design system.

• Discovery & App Status

  • Discovery & App Status now uses a donut chart built on our new Shadcn-based charting system.

  • Newly Discovered Apps is now a bar chart that aligns with the global time range filter and dashboard styling.

• AI Adoption & Usage (LLM usage)

  • New stacked bar chart for LLM Adoption by Users, breaking down usage across different LLM providers.

  • New widget: “LLM Adoption by Tools”

    • Mixed bar chart showing total LLM requests by tool/provider for the selected time range.

    • On hover, tooltips include the top 3 users by request volume for each tool (currently wired for live or placeholder data depending on backend readiness).

• Risk & Exceptions

  • New card list for:

    • Individually Approved Apps with Unauthorized Activity

    • (PII-related cards are scaffolded but will ship later with the broader PII feature set.)

  • Card lists support loading, empty, and error states consistent with the rest of the dashboard.

Under the hood

• All new charts and cards leverage our Shadcn-based design system for consistent layout, typography, colors, and components.

• Widgets respect the global time range filter so you can analyze trends for any selected window.

We’ve added a new IT onboarding experience to the Swif Desktop App so new hires can see and complete their onboarding checklist without signing into Swif.

What’s new

• Onboarding Checklist page in the desktop app

  • New “Onboarding Checklist” page for employees, based on the latest designs.

  • Checklist items, grouping, and labels are fully driven by your Employee Checklist Templates.

• No-login employee experience

  • New hires can access and complete their onboarding checklist without logging into Swif.

  • The app uses a secure, device-serial–based token flow for all checklist API calls in this mode.

• Real-time progress & auto-hide behavior

  • Employees can mark items as completed directly from the desktop app.

  • Completion state is persisted to the backend so admins see accurate progress.

  • When all tasks are done, the Onboarding Checklist page is automatically hidden and the user is redirected back to the Overview page.

  • If there are no pending tasks (empty or all completed), the checklist page will not appear.

• Template-driven mandatory tasks

  • Mandatory tasks are honored from your configured templates (e.g., Swif MDM templates).

  • No hardcoded mandatory items — everything comes from backend/template configuration.

Technical notes

• Implements device-serial–based token auth for checklist APIs in the desktop app.

• Available in Swif Desktop App build 1.0.155+1 for:

  • macOS

  • Windows

  • Linux x86

  • Linux ARM64

Docs

• Learn more: Onboarding Checklist in the Swif Desktop App (No-Login needed) | Help Center | Swif.ai