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.

Deterministic Code
GitHubServiceNowEngineeringOperationsData SyncNotifications & Alerts

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.

Additional information

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.

Frequently asked questions

Does every merged pull request open a change request?
No. The workflow only fires when a PR is merged and carries the label you choose, so day to day feature PRs do not flood ServiceNow.
What if the engineer who merged the PR does not exist in ServiceNow?
If the lookup by email returns no match, the workflow falls back to leaving the change request unassigned so your change manager can route it manually.
Can I use this with GitHub Enterprise Server or a self hosted ServiceNow instance?
Yes. Both connections work with your own instance URLs as long as they are reachable, and you provide the matching credentials during setup.
Will it work if my team uses a different label like change-required?
Yes. The label that gates change request creation is a setting on the workflow, so you can point it at any label name your team already uses.
Does the change request get linked back to the GitHub PR?
Yes. The PR title, body, author, and a direct link to the merge are written into the change request, and the new CR number is posted as a comment on the PR.

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.