Behavior notes in this article are current as of July 2026. For the up-to-date behavior category of any specific application, always refer to Third-Party Patching Best Practices.
What Automox controls, and what it does not
Automox delivers third-party updates using each vendor's official installer and complies with that installer's requirements. Automox does not monitor for active calls or meetings inside applications, and it does not control how a vendor's installer behaves toward a running application. Vendors change their installers over time, which is why this article explains the model rather than promising per-version details.
What Automox does control is whether an update attempt proceeds when the application is running. Each supported title carries a defined update behavior, published in the Best Practices table linked above, and the Automox agent enforces it on every policy run.
The three update behaviors and what they mean for calls
- The update waits until the application is closed ("App will NOT patch when running"). Most conferencing and VoIP applications are in this group. If the application is running when the policy executes, the update is not applied, nothing is closed, and no call is interrupted. The update stays in scope and is retried automatically on every subsequent policy run until one occurs while the application is closed.
- The update applies in place ("App is NOT shut down in order to patch"). The new version installs alongside the running application. Nothing closes, and calls are unaffected. The session in memory continues running the old version until the user relaunches the application, at which point the new version takes effect.
- The application is closed to complete the update ("App is shut down by vendor" or "App is shut down by Automox"). Either the vendor's installer or the Automox update process closes the application, and in most cases relaunches it once the update finishes. An active call in one of these applications can be interrupted. Titles in this group deserve deliberate scheduling, covered below.
What you will see in the console during a deferral
When a group 1 application is running at patch time, the attempt for that run does not complete. Depending on where you look, this can appear as an unsuccessful or incomplete attempt in the device's activity, while the package continues to show the update as available or scheduled. This is expected behavior, not an error: the device is healthy, the policy is working, and the update will apply on a later run. No partial installation occurs; the application simply stays on its current version until an attempt succeeds.
The flip side is worth planning for. An application that is running around the clock, such as a softphone that launches at login, can defer indefinitely. Since the point of the deferral is to protect the user's session, the fix is scheduling, not force.
Making updates land predictably
- Schedule around usage. A Patch Only policy targeting your communication apps, scheduled outside core working hours, resolves the vast majority of deferral loops. Devices that are on but idle overnight will patch cleanly.
- Use end-user notifications for group 3 titles. Patch policies can notify users before installation and allow deferrals, so a user in a call can postpone the update to a convenient moment instead of being interrupted. See Policy for Third-Party Apps with a Shutdown Requirement.
- Disable the vendor's own auto-updater where you patch through Automox. Communication apps commonly self-update. If both the vendor's updater and Automox are active, versions drift and reporting gets noisy. Most vendors document a managed-deployment setting to disable self-updates so your patch policy is the single source of truth.
- Mind the security tradeoff. A deferral means a known-vulnerable version can linger on devices where the app never closes. If you are patching a communication app for a security advisory, check the Software page for devices still reporting the old version after your patch window and consider a tighter maintenance window for the stragglers.
Calls in a browser
Meetings held in a browser tab (Google Meet, or Zoom and Teams web clients) follow the browser's update behavior, not the meeting vendor's. Browsers in the Automox catalog generally update in place: the running browser keeps its current version until relaunch, so an in-progress call in a tab is not interrupted by the browser being patched. The new browser version takes effect the next time the browser restarts.
Zoom (as of July 2026)
Zoom's installer will not apply an update while a meeting or Zoom Phone call is in progress, and Automox complies with this. On Windows, if a policy runs during an active call, the meeting continues uninterrupted, the update records as incomplete for that run, and it retries on the next policy run. When no call is in progress, the update applies and restarts the Zoom client. On macOS, Automox never force-closes Zoom, so an active meeting is not interrupted; an update that cannot apply while Zoom is in use retries on the next run. To keep Zoom versions consistent, disable Zoom's built-in auto-update through Zoom's deployment settings; see Updating Zoom to the latest version.
Slack (as of July 2026)
On macOS, Slack is closed and relaunched to apply the update, and an active call or huddle can be interrupted. Slack is the most common reason to adopt the off-hours scheduling above. On Windows, the Microsoft Store package updates in place without closing the app.
Microsoft Teams
The new Teams client is updated by Microsoft's own service model, and Microsoft's documentation is the authority on its update behavior; see Teams updates. Where Automox packages for Teams exist, their current behavior category is listed in the Best Practices table.
If you use the Third-Party Overrides Worklet
Overrides deliberately change group 1 behavior by force-closing selected applications so updates can apply. That is exactly what some environments want for compliance, but be aware of the consequence: if you have deployed overrides for a communication app, an active call in that app can be interrupted during a patch window. Review your override list against the apps your users take calls in.
Frequently asked questions
Will Automox drop my users' calls? For applications in groups 1 and 2, no. For group 3 applications, and for any app you have added to the overrides worklet, a call can be interrupted, which is why we recommend off-hours scheduling for those titles.
An update has shown as pending for days. Is something wrong? Almost always this means the application is running whenever the policy fires. Nothing is broken; schedule a run for a time the app is closed.
Does a deferred attempt count as a policy failure? No. The attempt is recorded as incomplete and the policy retries automatically. No remediation is needed on the device.
Can Automox detect whether a user is in a call before patching? Automox does not perform in-app call detection. Where an update avoids interrupting a call, that protection comes from the behavior category (the app was not going to be closed in the first place) or from the vendor's installer, as with Zoom.