Release Custom Rules

The Release Custom Rules page allows administrators to configure compliance checks that govern how releases are processed through their lifecycle. By defining these rules, organizations can ensure that release records are complete, all prerequisites are met at each stage, and proper documentation is maintained.

These rules act as safeguards to enforce release management policies, maintain data integrity, and align release execution with ITSM best practices.

To view the Release Custom Rules page, navigate to Admin > Release Management > Release Custom Rules.

The page is organized into multiple rule categories, each accessible from the left-hand panel:

Submitted Rules

This tab allows administrators to define validation checks that must be met before a release can be moved into the Submitted state. These rules ensure that essential information is captured at the time of submission.

1. Mandatory Field

Specifies fields that must be completed before the release can be submitted.

• Assignee: Ensures a responsible technician is assigned to the release.
• Technician Group: Requires assigning the release to a valid group.
• Release Type: The type of release (e.g., Major, Minor, Emergency) must be specified.
• Location: Requires specifying the location affected by the release.
• Category: Ensures correct categorization of the release.
• Release Manager: A Release Manager must be assigned to oversee the release.

Planning Rules

This tab allows administrators to define validation checks that must be met before a release can enter the Planning stage. These rules ensure that all necessary plans and impact assessments are documented.

1. Mandatory Field

Specifies fields that must be completed before the release moves to planning.

• Assignee: Ensures a responsible technician is assigned.
• Technician Group: Requires assigning the release to a valid group.
• Release Manager: A Release Manager must be assigned.
• Planning-Impact: The potential impact of the release must be assessed and documented.
• Backout Plan: A plan for reverting the release if it fails must be documented.
• Rollout Plan Dates: The dates for the rollout must be planned and recorded.
• Location: Requires specifying the location.
• Category: Ensures correct categorization.
• Release Engineer: The engineer for the release must be assigned.
• Rollout Plan: A detailed rollout plan must be documented.
• Release Schedule Dates: The schedule for the release must be recorded.

Build Rules

This tab allows administrators to define validation checks that must be met before a release can be moved to the Build stage.

1. Mandatory Field

Specifies fields that must be completed before the release can be built.

• Assignee: Ensures a responsible technician is assigned.
• Release Engineer: The engineer responsible for the build must be assigned.
• Technician Group: Requires assigning the release to a valid group.
• Build Plan: A detailed build plan must be documented.

Testing Rules

This tab allows administrators to define validation checks that must be met before a release can enter the Testing stage.

1. Mandatory Field

Specifies fields that must be completed before the release can be tested.

• Assignee: Ensures a responsible technician is assigned.
• QA Manager: The manager responsible for quality assurance must be assigned.
• Technician Group: Requires assigning the release to a valid group.
• Test Plan: A detailed test plan must be documented.

Deployment Rules

This tab allows administrators to define validation checks that must be met prior to deployment.

1. Mandatory Field

• Assignee: Ensures a responsible technician is assigned.
• Release Engineer: The engineer responsible for deployment must be assigned.
• Technician Group: Requires assigning the release to a valid group.

2. Require State

• All Tasks must be closed: Prevents deployment if any linked tasks are still pending.
• All Associated Changes must be closed: Ensures that all changes included in the release are completed.

Review Rules

This tab allows administrators to define validation checks that must be met before a release can be moved into the Review stage.

1. Mandatory Field

• Assignee: Ensures a responsible technician is assigned.
• Release Reviewer: The person responsible for reviewing the release must be assigned.
• Technician Group: Requires assigning the release to a valid group.

2. Require State

• All Associated Changes must be closed: Ensures all changes are closed before the final review.
• Release must have at least one worklog: Ensures that work has been logged against the release.

Required Note Rules

The Required Note Rules section allows administrators to enforce that technicians add mandatory notes whenever specific actions or field changes occur on a release request. This improves transparency and accountability throughout the release lifecycle.

1. User Interaction

• Reopen: Enforces that a note must be added whenever a release is reopened.
• Planning: Cancelled: Requires a note when a release is cancelled during the planning phase.
• Review: Completed: Requires a note when the review is completed.
• Testing: Failed: Requires a note when the testing phase fails.
• Submitted: Rejected: Requires a note when a submitted release is rejected.
• Review: Failed: Requires a note when a release fails its review.
• Build: Cancelled: Requires a note when the build is cancelled.
• Deployment: Failed: Requires a note when the deployment fails.

2. Release Updated

Specifies which field changes require the technician to provide a note.

• Assignee: A note must be added when changing the assigned technician.
• Technician Group: Requires a note when the release is moved to a different group.
• Urgency: Ensures justification when urgency is updated.
• Category: Captures reasoning when the release is re-categorized.
• Release Type: Requires a note when the release type is updated.
• Status: Requires a note whenever the release status is updated.
• Location: Requires a note when the release’s location is updated.
• Priority: Captures justification when the release priority is updated.
• Impact: Enforces documentation when impact values are updated.
• Department: Enforces notes when reassigning to another department.
• Release Risk: Requires a note when the release risk is updated.

Show Dialog Rules

The Show Dialog Rules section allows administrators to configure confirmation prompts that appear when certain key fields of a release are updated.

1. Release Updated

• Assignee: Show a dialog when the release is reassigned to another technician.
• Technician Group: Display confirmation when transferring releases across groups.
• Urgency: Show a dialog when urgency level is updated.
• Category: Confirm changes to release categorization.
• Release Type: Show a dialog when the release type is changed.
• Status: Show a dialog when the release status is updated.
• Location: Show a dialog when location details are updated.
• Priority: Confirm priority updates.
• Impact: Show confirmation when changing impact assessment.
• Department: Confirm when releases are reassigned to a different department.
• Release Risk: Show a dialog when the release risk is updated.

Add Worklog Rules

The Add Worklog Rules section allows administrators to control which technicians are permitted to add worklog entries to a release.

Worklog Addition Access

• Only Assignee: Only the technician assigned to the release is allowed to add worklog entries.
• Only Technician Group: Any technician within the assigned group can add worklogs.
• All Technicians: Any technician in the system can add worklogs to the release.
• Only Assignee or Technician Group: Both the assigned technician and members of the assigned group can add worklogs.

note

Tasks created without any reference module will not have any configuration; hence, all technicians can add a worklog.

Example Scenario: You cannot create a task when the release is in Approval stage.