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.
GitHub
ServiceNowEngineeringOperationsData SyncNotifications & AlertsBuild 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 does this prompt do?
- 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 do I need to use this?
- 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 can I 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.
FAQs
Does every merged pull request open a change request?
What if the engineer who merged the PR does not exist in ServiceNow?
Can I use this with GitHub Enterprise Server or a self hosted ServiceNow instance?
Will it work if my team uses a different label like change-required?
Does the change request get linked back to the GitHub PR?
Related templates
See every recent deploy across all your Heroku apps in one timeline, then roll back, restart, or file an incident without leaving the screen.
Every tool you run or are weighing up, with the Hacker News threads that actually mattered, project health beside them, and a written verdict you keep.
One matrix that shows every workspace variable side by side, flags what is missing or mismatched, and fixes it only after you approve each change.
See everything engineering shipped next to the docs pages that cover it, so the work nobody labelled stops slipping through.
Every library you have adopted, are trialing, are assessing or have put on hold, on one board, with live research and a written recommendation on each card.
See every take-home waiting on a verdict, read the code in the app, and have it built and tested in a throwaway machine instead of on your laptop.
Stop hand filing change requests after every production merge.
Connect GitHub and ServiceNow once, and Geni opens the change request, assigns it to the right engineer, and links it back to the merge automatically.