If your organization uses a custom ServiceNow instance URL, you may have noticed an annoying gap in the user experience: a workflow posts a link in work notes, but the link still points to *.service-now.com instead of your branded URL. ServiceNow supports company-branded custom instance URLs, and ReleaseOps is built to automate deployments across pipeline instances, so that mismatch stands out quickly for users who never access the platform through the default hostname.
In the scenario behind this article, ReleaseOps posts a health scan result into work notes, but the URL behind that note uses the default *.service-now.com domain. The work note is valid, but the click experience is not. Users land on the wrong hostname, hit a redirect they did not expect, or end up with a broken-looking journey.
Why this happens
ReleaseOps uses multi-instance management to connect the environments that participate in a deployment pipeline, while custom URLs sit alongside the instance’s designated service-now.com address. In setups like this one, it is possible for a workflow-generated link to surface the default hostname even though users are expected to work only through the custom URL.
A practical workaround
As a simple workaround I have created the ServiceNow Custom Domain Redirect Chrome extensionredirect-url-extension available in this GitHub repository. The extension is built to redirect *.service-now.com requests to your organization’s custom domain and already includes mappings for production, development, test, and stage environments.
This is a browser-side fix, not a platform-side change. In practice, it does not rewrite the work note text stored in ServiceNow. Instead, it changes where Chrome sends the request when a user opens a matching URL. That makes it a low-friction workaround for admins, release managers, and developers who just need the link to open in the right place. This is an inference from the extension’s design and Chrome’s redirect model.
How the extension works
The extension is a Manifest V3 Chrome extension that uses Chrome’s declarativeNetRequest API. In the repository, manifest.json declares the extension metadata, the declarativeNetRequest permission, and the allowed ServiceNow hostnames, while rules.json contains the redirect rules that map each *.service-now.com host to the matching custom domain. Chrome documents that this API can modify requests through declarative rules without intercepting and viewing request content, which keeps the solution lightweight.
A typical mapping looks like this:
acmecorp.service-now.com → acmecorp.internal.acme.com
acmecorpdev.service-now.com → acmecorpdev.internal.acme.com
acmecorptest.service-now.com → acmecorptest.internal.acme.com
acmecorpstage.service-now.com → acmecorpstage.internal.acme.com
Installation
- Download the extension source from the live redirect-url-extension GitHub repository, either by cloning the repository or downloading the ZIP and extracting it locally.
- Open manifest.json and replace every mycompany placeholder with your own instance prefix. The sample manifest already shows separate host permissions for production, development, test, and stage.
- Open rules.json and replace both mycompany and mycustomurl.com with your real values. A quick find-and-replace is usually the fastest way to do this: replace mycompany with your instance prefix and replace mycustomurl.com with your custom domain.
- In Chrome, open chrome://extensions/, enable Developer mode, click Load unpacked, and select the folder that contains manifest.json.
- Verify the setup by opening your default instance URL, such as https://yourinstance.service-now.com. If the configuration is correct, Chrome should redirect you to the custom domain automatically, and the extension icon should show redirect activity.
Supporting additional environments
If your organization also uses environments such as UAT, training, or sandbox, add the extra host to host_permissions in manifest.json, then add a matching rule with a unique id in rules.json. After editing either file, reload the extension from chrome://extensions/.
Troubleshooting tips
If the redirect does not work immediately, start with the basics. Make sure Developer mode is enabled, confirm that the host_permissions entries in manifest.json match the urlFilter values in rules.json, and reload the extension after every edit. Also make sure the source and destination domains are different, otherwise you can create a redirect loop.
Final takeaway
If ReleaseOps is posting *.service-now.com links while your users work exclusively through a custom instance URL, this extension is a clean and practical workaround. It is easy to customize, easy to extend, and it uses Chrome’s native declarative redirect mechanism rather than a heavier scripting model. Until every workflow becomes fully custom-domain aware, this is a smart way to remove friction from the day-to-day ReleaseOps experience.
