"Run Once'" option for uninstall triggers Merged

Summary

I would like to propose a “Run Once” option for Uninstall triggers within Recast Application Workspace.

Currently, when automating uninstalls using Entra ID group membership, users are added to a designated Uninstall group. However, if users remain in that group after the uninstall completes, Application Workspace continues attempting the uninstall action. This results in unnecessary execution attempts and event noise.

A Run Once capability would prevent repeated uninstall attempts once the application has already been successfully removed.

Current Behavior

Typical automation flow:

1. User is added to an Entra ID Uninstall group.

2. Application Workspace detects membership and triggers uninstall.

3. The uninstall completes successfully.

4. User remains in the Uninstall group.

5. Application Workspace continues evaluating the trigger and re-attempts uninstall.

6. Repeated attempts generate unnecessary events and log entries.

Even when the app is no longer present, the evaluation cycle still fires, creating:

• Redundant uninstall execution attempts

• Event log noise

• Increased processing overhead

• Administrative confusion during monitoring

Problem Statement

Uninstall triggers based on group membership are state-persistent, not event-driven.

Because group membership remains true until manually removed, the system repeatedly evaluates the condition and re-runs the uninstall logic, even when:

• The application is already removed

• The uninstall exit code previously returned success

• No further action is required

This creates an inefficiency in automation workflows and introduces avoidable operational noise.

Proposed Enhancement

Add a “Run Once” Option to Uninstall Triggers

When enabled, this option would:

• Execute the uninstall action once per device/user per trigger instance.

• Record completion state.

• Suppress further uninstall attempts unless:

  • The trigger is manually reset, or

  • The application is detected as reinstalled.

Possible Implementation Approaches

Option 1: Completion State Tracking

Store a local or service-side completion flag when:

• Uninstall exit code indicates success

• Detection logic confirms application absence

Future evaluations would check:

If (UninstallCompleted = True) → Skip execution

Option 2: Detection-Based Short-Circuit

Before running uninstall:

If (AppDetected = False) → Do Not Execute

This would eliminate redundant executions while preserving group-based automation.

Option 3: Automatic Group Removal (Optional Enhancement)

Optionally remove the device/user from the uninstall group after success.

This may not be desirable in all environments but could be an advanced toggle.

Benefits

• Reduces unnecessary execution attempts

• Decreases event and log noise

• Improves automation hygiene

• Reduces backend processing load

• Aligns uninstall triggers with one-time workflow expectations

• Provides parity with how many administrators conceptually expect “removal” workflows to function

Real-World Use Case

In automated lifecycle management:

• IT adds a user to an “Uninstall – AppName” Entra group.

• The application is removed.

• The user remains in the group for audit or policy tracking.

• Application Workspace continues to attempt removal on every evaluation cycle.

A Run Once option would make the uninstall action behave as an event rather than a persistent enforcement loop.

Why This Matters

Uninstalls are typically transactional, not continuously enforced states.

Install enforcement makes sense as a persistent condition:

“Ensure the app exists.”

Uninstall enforcement often behaves differently:

“Remove the app once.”

Providing a Run Once toggle would align the product with real-world automation workflows and reduce unnecessary operational overhead.