Configuring Rules in Pre-Issuance and Post-Issuance Settings

Overview

Prerequisites

Before configuring rules, ensure the following:

• You have administrative access to the Policy Engine
• A Managed Certificate Policy is created or available for editing
• The rule configuration feature flag is enabled in your environment
• You understand the certificate lifecycle stages and issuance templates

To configure rules in Pre-Issuance and Post-Issuance Settings:

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

   The Policy Inventory page is displayed.

2. Create or select an existing Managed Certificate Policy.

   If creating a new policy, click (+ Create Policy) and select Managed Certificate Policy as the policy type.

   If editing an existing policy, locate the policy in the inventory and click the Edit icon.

3. Proceed through the policy configuration steps until you reach Step 4: Configuring Pre Issuance Tasks.

   The Pre Issuance Tasks configuration page is displayed with the Rules panel on the left.

4. Create a new rule by clicking + Add New Rule.

   The Add Rule dialog is displayed.

   Enter the following information:

   Table 1. Rule Configuration Fields

   Field	Description
   *Rule Name	Enter a unique name for the rule within the stage. Rule name becomes read-only after creation. Examples: "HighRiskCertificates", "InternalDomains", "WildcardCerts".
   Conditions	Define one or more conditions based on issuance template fields. Click + Add Condition to add conditions. Each condition requires: Attribute: Select from available template fields Operator: Choose operator matching the field type Value: Specify or select the condition value
   Logical Operator	When multiple conditions exist, select AND (all conditions must be true) or OR (any condition must be true).
   *Tasks	Add at least one task to the rule. Available tasks include: ITSM - Create ServiceNow Change Request Notifications - Send Email Notifications - Send Slack Hook Execution Configure Change Window Drag tasks from the Task panel on the right to the rule.
   *: Mandatory field

5. Configure task-specific parameters for each task added to the rule.

   For ITSM tasks: Configure ServiceNow instance connection, change request type, priority, and other change-related fields.

   For Notification tasks: Specify recipients (users, groups, email addresses) and message content.

   For Hook Execution: Select the hook and configure hook parameters and variable mapping.

6. Review all rule configuration details:
   • Rule name is unique and descriptive
   • Conditions are properly defined and combined
   • All required tasks are configured with valid parameters.

   Click Save to create the rule.

   The rule appears in the Rules list under Pre-Issuance Tasks stage.

7. If the rule contains an ITSM - Create ServiceNow Change Request task, the system automatically manages dependent tasks in Post-Issuance Settings.

   A matching rule is automatically created in Post-Issuance Settings with:

   • Same rule name
   • Same conditions
   • Dependent task: Update ServiceNow Request On Success.
   Note: If a rule with the same name already exists in Post-Issuance, the dependent task is added to that existing rule instead of creating a duplicate.
8. Navigate to Step 6: Configuring Post Issuance Settings.

   The Post Issuance Settings configuration page is displayed.

   Verify that rules from Pre-Issuance stage appear with their dependent tasks pre-configured.

9. Add additional Post-Issuance tasks to rules as needed (Email certificates, Notifications, and Hooks).

   For rules containing dependent ServiceNow tasks, ensure proper ordering:

   • Dependent tasks (SERVICE_NOW_CR_UPDATE) appear first in execution order
   • Independent tasks follow after dependent task completion
10. Save the Post-Issuance Settings configuration.

    All rule configurations, conditions, and task associations are persisted.

    Complete the policy creation by clicking Finish on the final step.

Managing Existing Rules

To modify an existing rule:

1. Navigate to Pre-Issuance Tasks or Post-Issuance Settings stage in policy configuration
2. In the Rules panel, click the Edit icon next to the rule name
3. Modify rule properties:
   • Rule name: Read-only (cannot be changed)
   • Conditions: Update condition values, operators, or add/remove conditions
   • Tasks: Add new tasks or remove existing tasks from the rule
4. Click Save to persist changes
5. Updates to shared rules (same name in multiple stages) automatically synchronize across stages

To delete a rule:

1. Navigate to the stage containing the rule (Pre-Issuance Tasks or Post-Issuance Settings)
2. In the Rules panel, click the Delete icon next to the rule name
3. Confirm the deletion when prompted
4. Note: The Default Rule cannot be deleted. System prevents deletion of rules containing dependent tasks unless the source dependency is first removed.

Important Considerations

• Rule Names: Must be unique within the same stage. Same rule name across stages is treated as a single logical rule.
• Dependent Task Management: When a ServiceNow task is added to Pre-Issuance, an automatic dependent task is created in Post-Issuance. Removing the parent task automatically removes the dependent task.
• Rule Conditions: Operator availability depends on the selected field type. Operators are dynamically populated based on field selection.
• Cross-Stage Synchronization: Condition updates in one stage automatically apply to matching rules in other stages.
• Task Ordering: Rules containing dependent tasks must appear before independent rules to ensure proper execution sequence.

ServiceNow Change Ticketing with Integration Hub Connector

For ServiceNow-based pre-issuance and post-issuance tasks, Policy Engine supports a connector-driven model through Integration Hub. A connector configuration is created per ServiceNow instance in Integration Hub, and Policy Engine renders ServiceNow task fields based on that connector configuration.

This approach allows customer-specific ServiceNow schemas to be used without requiring product-level field changes.

To reduce configuration errors before saving connector changes, Integration Hub provides a Validate action in the ServiceNow vendor configuration flow before the final update action. Validation is applied across configured serviceApiList entries and checks that request/response mapping structures are consistent.

For ServiceNow connector configuration, validation verifies:

• dynamicFieldList structure and mandatory attributes such as elementType, fieldId, and labelName.
• Supported field control types and value formats for each control type (for example, text values for text controls, and list values for selectable controls).
• payloadDataMapping keys map to valid fieldId entries defined in dynamicFieldList.
• Fallback compatibility by field type (for example, date-time picker fields do not support fallback configuration).

If validation fails, correct the reported mapping or schema errors and re-validate before proceeding with connector update.

Policy request audit data includes ServiceNow ticket number, request identifier, connector-driven payload references, and task errors to support end-to-end traceability.

When configured, the post-issuance close task uses the ServiceNow request identifier captured during pre-issuance request creation and updates the ticket to the configured closed state through the connector integration.

The ServiceNow change workflow is composed of the following tasks:

Supported Field Types and Operators

The following table lists supported template field types and their corresponding condition operators: