Open a ServiceNow change request when a production PR merges
When a pull request labeled production-deploy is merged in GitHub, file the matching ServiceNow change request and post the CR number back into the PR thread.
Integrations
GitHub
ServiceNow
Type
Categories
- Engineering
- Operations
Build a code workflow that turns merged GitHub pull requests into ServiceNow change requests so our ITSM compliance is satisfied without forcing engineers out of their PR flow.
Trigger: a GitHub webhook for the pull_request event. Only run the workflow when action is closed, the pull request's merged field is true, and the PR carries a label named production-deploy (make the label configurable). Ignore all other pull_request events.
Step 1. Call GitHub's Get a Pull Request action using the repository owner, repo, and pull_number from the webhook payload. Pull title, body, user.login, user.email (or the head commit author email if user.email is null), html_url, base.ref, additions, deletions, and the commits list.
Step 2. Look up the merging engineer in ServiceNow. Use ServiceNow's List Users action on the sys_user table, filtered by email equal to the PR author email. Take the first result's sys_id as assigned_to. If no user is returned, leave assigned_to blank so the change manager can route it manually.
Step 3. Call ServiceNow's Create Change Request action with these field mappings: type = standard, short_description = PR title, description = PR body followed by a line that says "GitHub PR: {html_url}", implementation_plan = the PR body (or the section marked Implementation in the PR description if present), justification = any GitHub issue references parsed out of the PR body (for example, lines like "Closes #123"), assigned_to = the sys_id from step 2, planned_start_date = now in ServiceNow's expected datetime format. Capture the returned change request number (for example, CHG0030042) and its sys_id.
Step 4. Call GitHub's Create an Issue Comment action on the same pull request (issue_number = pull_number) with a short message like: "ServiceNow change request {number} opened for this deploy. Assigned to {author or 'change manager for routing'}." Include a link to the change request in ServiceNow if the instance URL is known.
Error handling: if the ServiceNow user lookup fails, still create the change request unassigned. If Create Change Request fails, post a comment on the PR explaining the failure so the engineer knows to file the change record manually. The whole pipeline is deterministic and there are no judgement calls, so ship it as a code workflow with discrete nodes.
What it does
- Watches GitHub for pull requests that close as merged and carry your production deploy label.
- Files a standard change request in ServiceNow pre-filled with the PR title, description, author, and a link back to the merge.
- Looks up the merging engineer in ServiceNow by email so the CR is assigned to the right person, not a shared queue.
- Drops the new change request number back into the GitHub PR as a comment so the engineer never has to leave their merge thread.
What you’ll need
- A GitHub account with admin access to the repositories you want to track, so the workflow can receive merge events.
- A ServiceNow login that is allowed to create change requests and read the user directory.
- A label on your repository (for example, production-deploy) that your team applies to PRs that need a change record.
- Engineers' GitHub emails matching their ServiceNow user emails, so the assignment lookup can find them.
How to customize it
- Swap the trigger label (production-deploy, prod-release, change-required) to match what your team already uses on PRs.
- Adjust the change request fields, such as risk level, category, or default assignment group, to match your ITSM standards.
- Change the comment that gets posted back to GitHub, for example adding the approver group or a link to your CAB calendar.
Use cases
- Data Sync
- Notifications & Alerts
