Rule-Based Task Execution in Managed Certificate Policies

The Policy Engine implements deterministic rule-based task execution to manage tasks within certificate lifecycle stages. This section explains how rules are evaluated, executed, and how dependent tasks are automatically managed.

Overview

Rule-based task execution enables administrators to define deterministic behavior for policy execution. The Policy Engine evaluates rules in a specific order and ensures that only one rule's tasks execute per lifecycle stage, with automatic handling of dependent tasks and variable isolation.
Note: Stage rule configuration and execution support is available for approval, pre-issuance, and post-issuance setting stages.

To understand rule-based task execution:

  1. Navigate to (Menu) > Policy Engine > POLICY MANAGEMENT > Policies. The Policy Inventory page is displayed.

    The Policy Inventory page is displayed.

  2. Select a policy or create a new Managed Certificate Policy to view the configuration stages.
  3. Review the Approval, Pre-Issuance Tasks and Post-Issuance Settings stages to see rules in action.

Understanding Rule Execution Priority

Rules within each lifecycle stage are evaluated in a deterministic manner to ensure predictable execution.

To understand rule execution priority:

  1. Rules are evaluated in left-to-right order based on their configuration position in the policy.
  2. The system evaluates each rule's condition against the current request data.
  3. The first rule whose condition evaluates to true is selected for execution.
  4. Once a rule is selected, no other rule in the same stage executes.
  5. If no rule condition is satisfied, the Default Rule executes as a fallback.
Important:

Important Consideration: Only one rule per stage selected. Tasks from other configured rules are not executed. Plan your rule conditions to ensure proper coverage.

Rule Execution Properties

Property Description
Evaluation Order Rules are evaluated strictly left-to-right based on configuration position. The first matching rule is selected.
Single Rule Selection In each stage, only one rule is selected for execution. Tasks from other rules do not run.
No Match Handling If no configured rule condition is true, the Default Rule executes as a fallback.
Mandatory Default Rule Each lifecycle stage must contain exactly one Default Rule to handle unmatched scenarios.
Task Execution All tasks within the selected rule execute sequentially, including hidden dependent tasks.

Default Rule Behavior

The Default Rule serves as the fallback execution path when no other configured rules match the current certificate request.

Default Rule Characteristics

  1. No condition: The Default Rule executes automatically when all other rules fail to match.
  2. Mandatory presence: Each stage must have exactly one Default Rule.
  3. Task assignment: Configure fallback/default tasks that should execute for unmatched requests.
  4. Execution guarantee: Always executes when triggered, ensuring no requests fall through without action.

Example: Multi-Rule Configuration with Default

Consider the following Pre-Issuance Tasks stage configuration:

  • Rule 1 (Left): IF certificate_type = "wildcard" → Execute Hook X
  • Rule 2 (Center): IF certificate_type = "ev" → Execute Hook Y
  • Rule 3 (Right): IF certificate_type = "standard" → Execute Hook Z
  • Default Rule: Execute Hook Default (no condition)

When a certificate request arrives:

  • If certificate_type = "wildcard" → Rule 1 executes Hook X
  • If certificate_type = "ev" → Rule 2 executes Hook Y
  • If certificate_type = "standard" → Rule 3 executes Hook Z
  • If certificate_type = any other value → Default Rule executes Hook Default

Automatic Dependent Task Management

The Policy Engine automatically manages hidden dependent tasks to ensure proper task coordination across lifecycle stages.

Enroll Certificate Hidden Dependent Task

  1. A hidden dependent task from the Enroll Certificate action is automatically added to all rules in Pre-Issuance Tasks and Post-Issuance Settings stages.
  2. This task appears in the system but is not editable by administrators.
  3. The hidden task cannot be removed from any rule.
  4. This task always executes when its parent rule is selected.
Note:

Note: These hidden dependent tasks ensure proper coordination between the Policy Engine and the Enroll Certificate action. They must remain in place for correct policy execution.

ServiceNow Failure Handling

  1. When a rule in the Pre-Issuance Tasks stage contains the task "Create ServiceNow Request":
  2. The system automatically creates a hidden dependent task "Update ServiceNow Request On Failure" in the Post-Issuance Settings stage under the same rule.
  3. This dependent task is not manually configurable.
  4. The dependent task remains logically bound to its parent task across stages.
  5. When certificate enrollment fails, this task updates the ServiceNow request status to maintain synchronization.
Stage Configured Task Auto-Generated Dependent Task
Pre-Issuance Tasks Create ServiceNow Request (manual) N/A
Post-Issuance Settings Other configured tasks Update ServiceNow Request On Failure (auto-generated, hidden)

Variable Scope and Isolation

Variables are scoped appropriately within rules and across lifecycle stages to enable proper data flow while preventing unintended cross-rule access.

Variable Scope Within Stage

  1. Variables created by a task within a rule are accessible only to subsequent tasks in the same rule.
  2. Variables from Rule 1 are not accessible to tasks in Rule 2, Rule 3, or any other rule in the same stage.
  3. Each rule maintains an independent variable namespace during execution.

Example: In Pre-Issuance Tasks with two rules:

  • Rule 1: Hook Task creates output variable correlation_id
  • Rule 1: Notification Task can reference ${correlation_id}
  • Rule 2: Hook Task cannot access correlation_id
  • If Rule 2 is selected, Hook Task in Rule 1 never executes

Variable Scope Across Stages

  1. When transitioning to a new lifecycle stage, all variables from previous stages become available.
  2. Variables from all rules in previous stages are accessible in subsequent stages, regardless of which rule was selected.
  3. This enables data flow across lifecycle stages for logging, notifications, and conditional logic.

Example: Multi-Stage Variable Flow

  • Pre-Issuance Tasks Stage: Rule A runs Hook → creates variable request_id
  • Post-Issuance Settings Stage: Notification task can reference ${request_id}
  • Variables from all Pre-Issuance rules are available regardless of selection in Post-Issuance

Error Handling and Field Notifications

The Policy Engine provides comprehensive error notifications to prevent silent misconfiguration when form fields used in rules are modified or deleted.

Field Deletion Notification

  1. When a form field used in any rule condition is deleted, the system identifies affected rules.
  2. A notification is displayed indicating the referenced field is no longer available.
  3. The notification appears while editing the lifecycle stage.
  4. Impacted rules are clearly marked for review and correction.

Field Value Updated Notification

  1. When a form field value (option) used in a rule condition is updated or removed:
  2. The system notifies administrators that the configured value has changed or is no longer valid.
  3. The notification appears while editing the stage.
  4. Administrators can identify and update affected rules accordingly.

Example Scenario:

  • Certificate type field had option "wildcard" → renamed to "multi-domain"
  • Rule with condition "certificate_type = wildcard" triggers update notification
  • Administrator must manually update the rule condition to "multi-domain"

Common Error Types and Impact

Error Type Impact and Mitigation
Deleted Field Rule cannot evaluate condition. Update rule condition or remove field reference immediately.
Updated Field Value Rule condition may not match correctly. Verify condition logic and update value reference.
Missing Default Rule Unmatched requests fail. Ensure each stage has a Default Rule to handle edge cases.
Misconfigured Condition Logic Rule evaluated incorrectly. Review condition operators and field-value mappings.

Feature Flag Enablement

Rule-based execution is controlled by a configuration feature flag that enables administrators to toggle between rule-based and legacy execution models.

When Feature Flag is Enabled

  • Rule-based execution logic is applied
  • Rule-based UI is visible in the Policy Engine
  • Rules are evaluated according to defined conditions
  • Hidden dependent tasks are automatically managed
  • Rule-level variable isolation is enforced

When Feature Flag is Disabled

  • Rule-based UI is hidden from administrators
  • Legacy (non-rule-based) execution behavior is used
  • Rule-based logic is not evaluated
  • Existing policy configurations are not corrupted
  • Tasks configured under default are executed

Configuring the Feature Flag

You can enable or disable the feature flag using one of the following methods:

Method 1: Using the Database (Tenant-Specific, Highest Priority)

This method applies the configuration at the tenant level and overrides other settings.
  1. Run the following database script to update the feature flag:
    db.avx_app_metadata.update(
  {"_id":"POLICY_ENGINE_DISABLE_STAGE_RULE"},
  {
    "description":"To disable policy engine stage rule support",
    "subsystem":"general",
    "value":"true"
  },
  true
);
  2. Restart the following pods to apply the changes:
    • avx-platform-core
    • avx-subsystems
    • avx-subsystems-sync

Method 2: Using Pod Environment Variable (Pod-Level Configuration)

This method applies the configuration at the pod level and affects all tenants within the pod.
  1. Set the required environment variable in the following pods:
    • avx-platform-core
    • avx-subsystems
    • avx-subsystems-sync
  2. Restart the pods after applying the environment variable changes.
Switching Feature Flag Safely
  1. No configuration corruption: Switching the flag does not corrupt existing rule configurations.
  2. Backward compatibility: Disabling the flag reverts to legacy behavior without losing rule definitions.
  3. Rollback capability: Configurations are preserved if the flag is re-enabled later.
  4. Test first: Test in non-production environment before enabling in production.

Complete Rule Execution Workflow

The following steps illustrate the complete rule evaluation and execution process:

  1. Policy Execution Initiated: A certificate request triggers the policy execution.
  2. Stage Entry: System enters Pre-Issuance Tasks stage (or another configured stage).
  3. Rule Iteration: System iterates through rules from left-to-right position.
  4. Condition Check: For each rule, evaluate its condition against request data.
  5. First Match Found: When a condition evaluates to true, select that rule for execution.
  6. Task Execution: Execute all tasks configured in the selected rule sequentially.
  7. Hidden Task Execution: Execute hidden dependent tasks (Enroll Certificate, ServiceNow failure if applicable).
  8. Variable Capture: Capture output variables from tasks (isolated within rule scope).
  9. Stage Completion: Stage completes with all tasks executed.
  10. Stage Transition: Move to next stage with variables from all previous rules available.
  11. Repeat: Repeat process for next stage.
  12. Default Rule Fallback: If no rule matched any stage, execute Default Rule instead.

Best Practices for Rule Configuration

  • Comprehensive condition coverage: Ensure rule conditions cover all possible certificate types and scenarios.
  • Default Rule requirement: Always configure a Default Rule in each stage to handle edge cases.
  • Rule order matters: Place more specific rules before general rules (left-to-right).
  • Consistent naming: Use clear, descriptive rule names to identify their purpose.
  • Monitor field changes: Review notifications when form fields or values are modified.
  • Test thoroughly: Test rule conditions with different certificate types before deployment.
  • Variable documentation: Document variables created by tasks that are used across stages.
  • Avoid circular logic: Ensure rule conditions do not create circular dependencies.

Important Considerations

  • One rule per stage: Only one rule executes per stage. Other rules are not evaluated.
  • Default Rule mandatory: Each stage must have exactly one Default Rule.
  • Left-to-right priority: Rule order determines evaluation priority. Reorder rules to adjust priority.
  • Variable isolation: Variables are scoped per rule within stage. Plan variable usage accordingly.
  • Hidden tasks automatic: Do not attempt to manually modify Enroll Certificate or ServiceNow dependent tasks.
  • Error notification response: Always respond to field deletion/update notifications immediately.
  • Feature flag status: Verify feature flag is enabled before expecting rule-based execution.