How to submit a deployment change request

Change Management · Deployment Requests | Last updated: June 2026 | Applies to: All business units | Audience: Engineering, DevOps, Product, CloudOps

1. OVERVIEW

The Change Management System (CMS) is the single place to submit deployment change requests across all business units - Aerialink, Convey, West Utilities, Agent 511, and i2SMS. Every production or stage deployment that falls outside the self-deployment criteria must be submitted to CCB.

⚠️ Important: All product deployments require CCB approval before execution. Do not begin any stage or production deployment until your change request has been reviewed and approved by the Change Control Board (CCB).

The system guides you through a short workflow assessment to determine the correct approval path, then collects deployment details, scheduling information, and a risk assessment. On submission, the request is automatically routed to the appropriate approvers.

👉 Submit your deployment request here: https://ccb.goconvey.com/

2. CHANGE TYPES

The currently available change type is Product Deployment. Project Deployment is coming soon.

Product deployment sub types:

Major Release - Significant new functionality, architectural updates, or changes with broad user impact. Requires the longest lead time and full CCB review.
Patch Release - Bug fixes, minor enhancements, or maintenance changes with limited scope. Standard lead time applies.
Emergency Hotfix - Critical production fixes required to restore service or address an active incident. Expedited approval path; ELT sign-off required for high-risk hotfixes.

3. STEP 1 - SELECT CHANGE TYPE

Open the Change Management System at https://ccb.goconvey.com/ and select Product Deployment from the Change Type options. The form sections will expand progressively as you complete each section.

Select the appropriate Deployment Type (Major Release, Patch Release, or Emergency Hotfix) from the dropdown. Your selection affects the required lead time and approval path.

ℹ️ Not sure which deployment type applies? Use Patch Release for routine changes. Select Major Release if the change includes new features, architecture changes, or affects multiple services. Use Emergency Hotfix only for active production incidents or critical business-blocking issues.

4. STEP 2 - CHANGE DETAILS

Provide complete and accurate information in all required fields. This information is used by the CCB to evaluate the change and by operations teams during and after the deployment.

Title (required) - A short, clear description of the change. Example: "Patch v2.4.1 - fix session timeout bug"
Description (required) - Detailed explanation of what is changing, why, and the expected outcome. Be specific - vague descriptions delay CCB approval.
Requester (required) - The person submitting the change request. Type to search registered users.
Business Unit (required) - The business unit responsible for this change: Aerialink, Convey, West Utilities, Agent 511, or i2SMS.
Environment (required) - Target environment: Development, UAT, Stage, or Production.
Product (required) - The product or service being changed. Select from the available product list for your business unit.
Components impacted (required) - Check all that apply: Code, Config/DB, Infrastructure.
Release Version (required) - The version number or tag being deployed, e.g. v1.2.3.

5. STEP 3 - DEPLOYMENT PLANNING

Provide the scheduling, ownership, and procedural details for the deployment. Incomplete planning information is the most common reason change requests are returned by the CCB.

Scheduling fields:

Deployment Start Date & Time (PST) (required) - Scheduled start date and time. Must respect the required lead time for your change type. See Lead times section below.
Deployment End Date & Time (PST) (required) - Estimated deployment end date and time.
Downtime (required) - Indicate whether the deployment will cause a service interruption. If Yes, specify the estimated downtime duration in hours.
Deployment method (required) - Select all that apply: CI/CD, Script, Manual, Other.

Ownership fields:

Responsible Developer (required) - The developer accountable for the deployment execution.
Responsible QA (required) - The QA engineer responsible for post-deployment validation.
Responsible CloudOps (optional) - The CloudOps team member supporting the deployment.

Plans and procedures:

Implementation plan (required) - Step-by-step description of how the deployment will be executed. Include pre-deployment steps (backups, notifications, freeze checks), the deployment execution sequence, and any manual intervention points.
Post-validation steps (required) - How you will confirm the deployment was successful. Include smoke tests or functional checks to run, monitoring dashboards to review, and acceptance criteria that must be met before marking complete.
Rollback plan (required) - Required for all change requests. Provide the rollback decision criteria (what triggers a rollback), step-by-step rollback procedure, rollback duration in hours, and rollback owner. Select Yes only if a tested rollback procedure exists and is ready to execute.
Lead time exception details (conditional) - Required only if the requested deployment date falls within the standard lead time window. Provide a clear justification for the exception.

🚫 No rollback plan = mandatory on-site hotfix requirement. Per change management policy, all deployments must have a documented rollback plan. Selecting "No" flags the request for escalated review and may prevent approval.

6. STEP 4 - RISK ASSESSMENT

The risk assessment calculates an overall risk score. The score determines the level of CCB review required and whether ELT sign-off is needed. Complete every field accurately — the risk score directly impacts your approval path.

Risk factors:

Weather / Season impact - External conditions that could affect deployment stability. Score 1 = no impact expected. Score 5 = critical impact, unsafe or highly unstable window.
Cross-functional team readiness - Whether all teams (CSM, Support, Engineering, Product) are informed and prepared. Score 1 = all teams aligned and confirmed. Score 5 = multiple teams not informed or ready.
Change complexity - Number and type of components involved. Score 1 = low, minimal components. Score 3 = high, many dependencies and complex interactions.
Code stability - Quality and stability of the code being deployed. Score 1 = stable, all tests passing. Score 3 = major issues present.
Environment readiness - Whether the target environment is prepared. Score 1 = fully ready and validated. Score 5 = environment not ready for deployment.
Rollback plan - Readiness and quality of the rollback procedure. Score 1 = tested rollback plan ready to execute. Score 5 = no viable rollback plan.
User impact - How many users are affected and the severity of disruption. Score 1 = no user impact. Score 5 = critical impact or business disruption likely.
Deployment method (risk) - How automated and reliable the pipeline is. Score 1 = fully automated and tested. Score 5 = ad-hoc or manual process with no safeguards.
Third-party dependencies - Risk introduced by external services or vendors. Score 1 = no dependencies. Score 5 = critical or unverified external systems.
Monitoring & alerts - Quality of monitoring coverage. Score 1 = comprehensive monitoring and alerting in place. Score 5 = no effective monitoring configured.

Risk score outcomes:

Low - Standard CCB review. Normal approval timeline applies.
Medium - CCB review with additional scrutiny. May require more detailed planning documentation.
High - CCB review plus mandatory ELT sign-off. Emergency Hotfixes with a high risk score require a minimum of 2 ELT approvals.

ℹ️ The risk score is calculated automatically as you complete each field. Review the Overall Risk indicator before submitting and consider whether you can reduce risk factors before the deployment window.

7. DEPLOYMENT REQUEST STATUS WORKFLOW

Once submitted at https://ccb.goconvey.com/, your change request moves through a defined set of statuses. Understanding these helps you track your request and take the right action at each stage.

All possible statuses:
CCB Review · ELT Review · Approved · Scheduled · Started · Extended · Rescheduled · Completed · Rolled Back · Cancelled · Rejected · Need Info

🚀 Standard lifecycle - success paths

Path 1: Standard completion
CCB Review → ELT Review (if needed) → Approved → Scheduled → Started → Completed
Outcome: Deployment successful within the allotted window.

Path 2: Deployment extension
CCB Review → ELT Review (if needed) → Approved → Scheduled → Started → Extended
Action required: Update the Status Page Notification to reflect the new estimated completion time.

🔄 Pivot & exception paths

Path 3: Rescheduling
CCB Review → ELT Review (if needed) → Approved → Scheduled → Rescheduled
Action required: Update the Status Page Notification with the new deployment date and time.

Path 4: Cancellation
CCB Review → ELT Review (if needed) → Approved → Scheduled → Cancelled
Action required: Pull down the Status Page notification immediately.

⛔ Rejection & clarification paths

Path 5: Executive / Board rejection
CCB Review → ELT Review (if applicable) → Rejected
Note: Feedback must be provided to the requester explaining why the change was not permitted.

Path 6: Administrative bounce — Need Info
CCB Review → Need Info
Note: Triggered when initial documentation is incomplete. The workflow pauses until the requester provides the necessary details, after which the request returns to CCB Review.

8. APPROVAL REQUIREMENTS

Scenario	Required approval
All product deployments	CCB approval required before execution
Emergency Hotfix (any risk level)	CCB approval + ELT approval required
Emergency Hotfix (high risk score)	CCB approval + minimum 2 ELT approvals

⚠️ Do not deploy without approval. Beginning a deployment before CCB or ELT approval is granted is a policy violation. If your scheduled date is approaching and approval has not been received, contact CCB directly.

9. LEAD TIMES

Change requests must be submitted with sufficient lead time for review and approval. Submitting within the lead time window flags your request as a lead time exception and requires written justification.

Deployment type	Minimum lead time
Major Release	6 weeks
Patch / Minor Release	3 weeks
Emergency Hotfix	Customer demand - expedited via ELT path

ℹ️ Lead time exceptions: If your deployment date falls outside the standard window, the form will display a Lead Time Exception Details field. Provide a clear, business-justified reason. Exceptions are reviewed by the CCB and are not automatically approved.

10. Team Workflows

Ops & Support Responsibilities

The Change Management UI is integrated with deployment notifications to improve visibility and communication.
A notification will automatically be posted to the #support-ops channel when a deployment is:

Scheduled
Extended
Started
Cancelled
Completed

The Support and Operations teams are responsible for:

Monitoring deployment notifications in the #support-ops channel.
Creating and maintaining the appropriate Status Page communications.
Updating Status Page messaging throughout the deployment lifecycle based on deployment status changes.

CCB Review Protocols

All Change Requests will be assigned to the CCB group by default.
When reviewing a Change Request in Zendesk, the assigned reviewer should take ownership of the ticket.
Continue reviewing requests for completeness, approvals, deployment windows, and implementation readiness prior to approval.

CloudOps Tracking Rules

When a deployment begins, the deployment status in the Change Request ticket must be updated accordingly. (Scheduled -> Started -> Extended/Cancelled/Completed/Rolled Back/Rescheduled)
Ensure deployment end date & time are updated correctly after the deployment is completed.
Ensure deployment progress is accurately reflected throughout the implementation window.
Update ticket status as milestones are reached and when the deployment is completed.

Product & Engineering Requirements

All deployment-related updates, progress, issues, risks, delays, or completion details must be documented directly within the Change Request ticket.
The CCB team should be proactively informed of any significant deployment updates, schedule changes, or issues that may impact the release.
The Change Request ticket should serve as the single source of truth for deployment activities and communications.

11. FREQUENTLY ASKED QUESTIONS

Who needs to submit a change request?

Anyone deploying to Stage or Production environments - unless the workflow assessment determines the change qualifies for self deployment. This applies to Engineering, DevOps, Product, and CloudOps teams across all business units.

Q: I am unable to access the Change Request UI and receive the error: "You haven't been assigned access to this application. Contact your IT administrator for more information."

A: The Change Request UI is protected by JumpCloud SSO. If you receive this error, you do not currently have the required access permissions. Please submit an IT request to be added to the Change Request Access group. Once your access has been granted, you will be able to log in to the application.

Can I submit a change request for a Development environment?

Development deployments typically do not require a change request. However, if the change also touches Stage or Production, a full change request is required.

What is the Change Control Board (CCB)?

The CCB is the cross-functional group responsible for reviewing, approving, and scheduling changes. It meets weekly (Tuesday) at 12:30 pm PST(CCB Weekly Meeting Link), and on an emergency basis when required. It is owned by Engg PMO. Members include Engineering, CloudOps, Customer Ops, and Product Management.

What happens if my change request is rejected?

The CCB will return the request with comments explaining what needs to be addressed. Common reasons include: incomplete rollback plan, insufficient lead time without valid justification, missing post-validation steps, or a high risk score without mitigations. Update the request based on CCB feedback and resubmit.

What does "self deployment allowed" mean?

Your change does not require a formal change request. You may proceed with the deployment using your team's standard practices. Self-deployment is typically granted for low-risk, non-production or single-tenant changes that do not involve code or configuration.

When should I use the Emergency Hotfix path?

Only for critical production issues requiring an immediate fix - active service outage, security vulnerability, or a business-critical bug causing data integrity issues. Do not use this path to expedite routine changes. All Emergency Hotfixes require ELT approval; high-risk hotfixes require at least 2 ELT approvals.

What does "Need Info" mean on my request?

Your initial submission was missing required documentation. The workflow has paused and an internal note or comment will detail what is missing. Provide the requested details as soon as possible so your request can re-enter CCB Review without losing its place in the queue.

Can I view the status of a submitted request?

Yes. Navigate to View All Requests in the top navigation bar of the Change Management System at https://ccb.goconvey.com/, or go directly to the Requests list view. You can filter by status, business unit, or requester.

CMS PORTAL Submit and view deployment change requests.
CCB MEETING CCB Weekly Meeting Link (Tuesdays at 12:30 pm PST).