IT & Security package

Change management with CAB

An RFC form scores change risk, routes to pre-approval, CAB or emergency CAB, then tracks implementation and the post-implementation review in your ITSM.

Starts from a formIntermediate~15 min setupv1.0.0
Download .utpkg 16 KBHow to install

About this package

What it does

Change management with CAB runs the change lifecycle from request to closure. The requester fills in an RFC: the system, change type (standard, normal or emergency), a description, the risk questions (customer impact, rollback tested, out of hours), the planned window and the backout plan.

The Change risk decision table turns those answers into a risk level and an approval path. Standard changes with little or no customer impact are pre-approved, emergencies go to the emergency CAB with a two-hour decision time and escalation, and everything else goes to the CAB. The change is registered in the ITSM straight away and an SLA tracks the window end. The CAB can approve, approve with conditions, reject, or defer to the next meeting, which brings the review back a week later.

Approved changes are marked scheduled and the requester is emailed. The implementer records the actual start and end and whether the change was implemented or rolled back, and the change manager completes the post-implementation review, which closes the change with a close code. Adapt the risk rules, the ITSM states and paths, and the people.

Starts from a form

Starts from a form: the requester fills in the RFC (Run dialog, or your service portal posting to the start API).

Someone fills in a form to start it: the workflow inputs are the start form (Run dialog in the app, or your own portal posting to the API), and people complete User Task forms along the way.

The flow

Step by step

  1. 1

    Submit the RFC

    The start form collects the system, change type, description, risk questions, window and backout plan.

  2. 2

    Assess risk

    The Change risk decision table sets the risk level, the approval path (Auto, CAB or ECAB) and whether to check the freeze calendar. The change is created in the ITSM.

  3. 3

    Approve

    Standard low-risk changes are pre-approved. The CAB or emergency CAB approves, approves with conditions, rejects or defers; deferred changes return to the CAB a week later.

  4. 4

    Schedule and implement

    Approved changes are marked scheduled and the requester is emailed. The implementer records the actual window and whether the change was implemented or rolled back.

  5. 5

    Post-implementation review

    The change manager records whether objectives were met, incidents caused and lessons learned; the change is closed with a close code and the requester emailed.

Change request — A requester submits an RFC; the Change risk rules decide between pre-approval, CAB and emergency CAB, then implementation and a post-implementation review close the change in the ITSM. The same canvas you get in the designer after installing.

Forms

The start form and the task forms

The workflow inputs are the start form: the Run dialog renders them, and your own portal can post the same fields. User Tasks show their fields and outcome buttons to the assignee.

Start form

Change request

Filled in by whoever starts the process

Requested by * requester_name · textYour name
Your email * requester_email · emailname@company.comWhere to send approval and closure updates
Change title * change_title · textShort title, e.g. "Upgrade order database to v16"
System * system · textSystem or configuration item being changed
Change type * change_type · select
standardnormalemergency
Standard (pre-approved model), normal (CAB) or emergency (ECAB)
Description * description · textWhat will be changed, why, and how it will be tested
Customer impact * customer_impact · select
noneminormajoroutage
Expected impact on customers during the window
Rollback tested rollback_tested · booleanHas the rollback been rehearsed in a test environment?
Out of hours out_of_hours · booleanWill the change run outside business hours?
Window start * window_start · datetimeYYYY-MM-DD HH:mmPlanned start of the change window
Window end * window_end · datetimeYYYY-MM-DD HH:mmPlanned end of the change window
Backout plan * backout_plan · textHow the change is reversed if it fails, and how long that takes
CAB chair (user id) cab_user_id · textOptional: user id of the CAB chair (overrides the default chosen on install)
Implementer (user id) implementer_user_id · textOptional: user id of the engineer implementing the change

User Task

CAB review

CAB: {{change_number}} {{change_title}} ({{risk_level}} risk)

Conditions (if approving with conditions) conditions · text
Change calendar and freeze periods checked freeze_checked · boolean
CAB notes * cab_notes · text
ApproveApprove with conditionsRejectDefer

User Task

Emergency CAB review

ECAB: {{change_number}} {{change_title}} (emergency)

Conditions (if approving with conditions) conditions · text
Change calendar and freeze periods checked freeze_checked · boolean
CAB notes * cab_notes · text
ApproveApprove with conditionsReject

User Task

Implement change

Implement {{change_number}}: {{change_title}}

Actual start (date and time) * actual_start · textPrefilled: {{window_start}}
Actual end (date and time) * actual_end · textPrefilled: {{window_end}}
Implementation notes implementation_notes · text
ImplementedRolled back

User Task

Post-implementation review

Review {{change_number}}: {{change_title}} ({{implementation_result}})

Objectives met objectives_met · boolean
Incidents caused (numbers) incidents_caused · text
Lessons learned lessons_learned · text
SuccessfulSuccessful with issuesUnsuccessful

From your code

Start a run over the API

Every workflow can be started over REST, MCP or the CLI, whatever its trigger, with the sample input below. Runs start straight away on the published version; replace <workflow id> with the id the install created.

REST

shell
curl -X POST "$USERTASKS_URL/api/v1/workflows/start" \
  -H "Authorization: Bearer $USERTASKS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"workflow_id":"<workflow id>","variables":{"requester_name":"Alex Morgan","requester_email":"alex.morgan@example.com","change_title":"Upgrade order database to PostgreSQL 16","system":"order-db-prod","change_type":"normal","description":"In-place major version upgrade of the order database cluster. Rehearsed twice in staging; read replicas upgraded first.","customer_impact":"minor","rollback_tested":true,"out_of_hours":true,"window_start":"2026-11-07T22:00:00Z","window_end":"2026-11-08T02:00:00Z","backout_plan":"Fail back to the untouched replica (15 minutes) and repoint the application connection string."}}'

CLI

shell
usertasks workflows inputs <workflow id>          # the start form: keys, types, required
usertasks workflows run <workflow id> --input requester_name="Alex Morgan" --input requester_email=alex.morgan@example.com --input change_title="Upgrade order database to PostgreSQL 16" --input system=order-db-prod … --wait

Inbound webhook

shell
usertasks webhooks create <workflow id>          # prints the hook slug and secret once
curl -X POST "$USERTASKS_URL/api/webhooks/inbound?hook=<slug>" \
  -H "Authorization: Bearer <webhook secret>" -H "Content-Type: application/json" \
  -d '{"requester_name":"Alex Morgan","requester_email":"alex.morgan@example.com","change_title":"Upgrade order database to PostgreSQL 16","system":"order-db-prod","change_type":"normal","description":"In-place major version upgrade of the order database cluster. Rehearsed twice in staging; read replicas upgraded first.","customer_impact":"minor","rollback_tested":true,"out_of_hours":true,"window_start":"2026-11-07T22:00:00Z","window_end":"2026-11-08T02:00:00Z","backout_plan":"Fail back to the untouched replica (15 minutes) and repoint the application connection string."}'

What's included

8 assets, ready to adapt

TypeNameDetails
Email templateChange approvedSent to the change requester when the change is approved and scheduled.
Email templateChange closedSent to the change requester when the post-implementation review closes the change.
Email templateChange rejectedSent to the change requester when the CAB rejects the change.
IntegrationIT service management
API referenceCreate change requestPOST /changes — Register the RFC in the ITSM change module with its type, risk and planned window.
API referenceUpdate change requestPATCH /changes/{{change_id}} — Move the change to a new state and record approval, implementation or review notes.
Decision tableChange risk7 rules — Risk level and approval path for a change from its type and the risk questions. Standard low-risk changes are pre-approved, emergencies go to the emergency CAB, everything else to the CAB. First matching rule wins.
WorkflowChange request32 steps — A requester submits an RFC; the Change risk rules decide between pre-approval, CAB and emergency CAB, then implementation and a post-implementation review close the change in the ITSM.

Requirements

What you connect it to

Credentials never travel in a package. The install wizard asks for what your environment must provide, or installs it incomplete until you finish setup.

Needs

  • REST API — A REST API integration: set its base URL and credentials on install.
  • Assignees — People in your workspace to receive the User Tasks (picked on install).
  • Email — Email delivery configured for the instance (EMAIL_PROVIDER), used for notifications.

After installing

  1. IT service management integration: set the base URL of your ITSM API and an API token. The references expect POST /changes and PATCH /changes/{id}; map the states (assess, scheduled, review, closed, rejected, deferred) and fields to your change module in Integrations.
  2. Assignees: pick the CAB chair, the emergency CAB approver, the default implementer and the change manager who runs post-implementation reviews. Runs can override the CAB chair and implementer with cab_user_id and implementer_user_id.
  3. Review the Change risk rules against your change policy: which answers make a change high risk, and which standard changes are pre-approved.
  4. Adjust the Wait for next CAB delay to your CAB meeting cadence.
  5. Email: configure EMAIL_PROVIDER on the instance so the approved, rejected and closed emails are delivered (the steps continue on error).

Asked for on install

  • Integration “IT service management”Required

    • Tokenconfig.auth_config.token
    • Base urlconfig.base_urldefault https://itsm.example.com/api· optional

  • Workflow “Change request” assigneesRequired

    • User for step “CAB review”nodes.8.config.assignee_id
    • User for step “Emergency CAB review”nodes.9.config.assignee_id
    • User for step “Emergency CAB review”nodes.9.config.escalation_user_id
    • User for step “Implement change”nodes.15.config.assignee_id
    • User for step “Post-implementation review”nodes.19.config.assignee_id

Install

Install it in your workspace

Works on UserTasks cloud and on any self-hosted instance. Installing creates the assets above; nothing runs until you complete setup and start it.

In the app

  1. Download change-management-cab-1.0.0.utpkg.
  2. Open Automations → Packages and drag the file onto the page (or choose Import package). Browse gallery there lists every gallery package without downloading by hand.
  3. Pick the file. The wizard verifies the checksum, every file hash and the signature, and shows the readme.
  4. Review the changes (what is created) and the data rows.
  5. Fill in the requirements, or tick Keep incomplete and finish later with Complete setup.
  6. Done: the workflow is published and active once setup is complete.

With the CLI

shell
curl -fLO https://usertasks.com/gallery/change-management-cab-1.0.0.utpkg
usertasks packages inspect change-management-cab-1.0.0.utpkg       # offline: checksum, hashes, signature
usertasks packages install change-management-cab-1.0.0.utpkg --dry-run
usertasks packages install change-management-cab-1.0.0.utpkg       # prompts for each requirement
usertasks packages install change-management-cab-1.0.0.utpkg --keep-incomplete --yes   # in CI; finish with:
usertasks packages complete change-management-cab -f values.yaml

Verify the download

File SHA-256
d4aa81da28c72501a6205d5464c9de77c53ae68d1fdcc9e4805f127ee8ef0729
Package checksum (what is signed)
sha256:d119e7e69fab3f621a7e0012d0c75e51f457113b25e2db9963eff669d6dbae5b
Signer
Unsigned preview build — compare the SHA-256 above

shasum -a 256 change-management-cab-1.0.0.utpkg should print the file SHA-256. How gallery packages are signed.

Versions

Version 1.0.0

  1. v1.0.02026-10-26First release.

Installing a newer version upgrades in place: local credentials and requirement values are kept, and changes you made are flagged first. How packages work

More packages

Related

Browse the whole gallery