How end-user elevation auto-approval rules work

Overview

End-User Elevation Auto-Approval Rules determine whether an incoming elevation request is automatically approved without technician intervention. These rules are evaluated as part of an Elevation Auto-Approval Policy and are designed to approve only trusted, well-defined applications or processes.

Auto-approval rules do not define who the rule applies to. Instead, rules inherit their scope from the policy they are added to.

This article explains how auto-approval rules are evaluated, how policy audience affects rule behavior, and how rule matching works during an elevation request.

How Policy Audience Affects Rules

Auto-Approval Rules always apply to the entire audience defined by the policy they belong to.

When you select a policy for a rule:

• The rule automatically applies to all customers or end-users included in that policy’s audience

• Rules cannot target a subset of users within the policy

• Changing the policy audience immediately affects all rules in the policy

Screenshot 
Select Policy for Rule modal showing policy name, status, and audience scope.

Important notes:

• Rules do not have their own audience settings

• Audience scope is controlled only at the policy level

• A rule added to a customer-scoped policy applies to all end-users in those customers

• A rule added to an end-user-scoped policy applies only to the selected end-users

How Auto-Approval Rules Are Evaluated

When an end-user submits an elevation request, CyberQP evaluates the request using the following process:

1. The request is checked against Active Elevation Auto-Approval Policies.

2. The policy’s Audience Scope is evaluated to confirm the request applies to the correct customer or end-user.

3. Each rule within the policy is evaluated.

4. The request is auto-approved only if all conditions in a single rule match.

Screenshot :
Elevation Request details view showing program metadata captured by CyberQP, including Publisher, File Name, Program Path, and File Hash.

If no rule fully matches the request, the request remains pending and requires manual approval.

Rule Matching Logic

Each auto-approval rule is evaluated independently. Rules do not combine conditions across multiple rules.

Important behavior to understand:

• All conditions in a rule must match for auto-approval to occur

• Matching is exact unless wildcards are used

• If a single condition fails, the rule does not apply

• The first matching rule approves the request

Screenshot callout:
Add Rule modal highlighting the condition fields used for rule evaluation.

Supported Rule Conditions

Auto-Approval Rules can include one or more of the following conditions:

• Publisher

• Program Path

• File Name

• File Hash (SHA256)

• Minimum Version

• Certificate Hash

Screenshot callout:
Rule creation modal with all supported condition fields visible.

Rules can be as strict or as flexible as needed depending on how many conditions are defined.

Wildcard Usage

Wildcards (*) are supported in the following fields:

• Publisher

• File Name

Example:

• File Name = Chrome*.exe
  Matches any executable that starts with Chrome and ends with .exe

Screenshot callout:
Example rule using wildcard matching in the File Name field.

⚠️ Important:
Always use wildcard conditions in combination with additional conditions to avoid overly broad rules.

Rule Strictness and Security

The number of conditions in a rule directly affects how restrictive the rule is:

• Fewer conditions
  Broader rule, more flexible

• More conditions
  Narrower rule, more secure

Screenshot callout:
Comparison of a loosely defined rule versus a tightly defined rule.

Policy Status Impact on Rules

Auto-Approval Rules inherit the status of the policy they belong to:

• Active Policy
  Matching rules immediately auto-approve incoming elevation requests

• Draft Policy
  Rules are saved but do not auto-approve requests

Screenshot 
Policy list showing Active and Draft statuses.

What Auto-Approval Rules Do Not Do

Auto-Approval Rules:

• Do not define their own audience

• Do not grant persistent local admin rights

• Do not approve partial matches

• Do not combine conditions across multiple rules

Screenshot
Pending elevation request where no rule matched within the policy.

Each elevated process requires its own rule and approval decision.

Related Articles

• Creating an Elevation Auto-Approval Policy

• Create a Rule from an Elevation Request and Add to a Policy

• End-User Elevation FAQs