Policy: Require Approval to Run Applications

This example shows a File Access policy that prompts for approval before allowing a user to run an application. It’s useful for demonstrating how to introduce an approval workflow for application execution across a group of endpoints (for example, a pilot group or a department).
What this Policy Does
When a user on any in-scope endpoint tries to run an application:
The request is evaluated by the File Access policy engine.
Because the policy is broadly scoped (all users, all applications), it matches most execution attempts on those endpoints.
The policy requires Approval before allowing the action to proceed.
Why it Behaves this Way
This policy is intentionally written as a “broad match” policy, then applies a control:
Enforced: The policy is active and will apply controls (not just log).
Approval control on success: When the policy matches, it triggers an approval workflow.
All users: A wildcard user filter makes it apply to any user account on in-scope machines.
All applications: A wildcard application filter makes it apply to any application being evaluated by this File Access policy.
Built-in checks: Standard checks (user, machine, file, date/time/day, certificate) are present. If those constraints aren’t narrowed (for example, no date/time/day/cert restrictions are provided), the policy behaves like a broad catch-all for execution on the targeted endpoints.
What the User Experiences
Most application launches on the targeted endpoints will generate an approval request.
The policy includes a user-facing notification message. If the message references a specific date or one-off event, replace it with something generic (or remove it) to avoid confusion in production.
Important Notes and Common Adjustments
High prompt volume: Because this applies to all applications, it can create a lot of approvals—especially when expanded to many endpoints.
Narrow the scope if needed:
Restrict the application filter to a specific set of executables or paths
Restrict the user filter to specific users/groups
Add certificate/publisher constraints to treat trusted vs. untrusted software differently
Add time/day/date restrictions for staged rollouts or business-hours-only enforcement
Example JSON
Last updated
Was this helpful?

