Default URL of KB article to Permalink URL

[Harsha34]

Hi,

I work on a custom application and we use a custom service portal. The portal has lots of widgets and buttons int it and end users are using it currently. 

When we click on KB Category Tree and select one article and click on it then it opens with the url . This is how it works OOB as well.

?id=kb_article_view&sys_kb_id=8b4b9fbb3bff285y72b466a985e45a87&kb_category=25546ec197290e102e00bdb8c253af6f

When we permalink this article and open in anew tab the below url opens:(OOB)

?id=kb_article_view&sysparm_article=KI447####

Requirement is to replace sys_kb_id URL with Permalink URL.

I understand that they would be always able to see the latest version by doing this. But I am afraid doing this can break several other functionalities that are running at the backend although we have set this up in the widgets that they should show up in a similar way on permalink as well, but there are OOB script includes inside these which is using sys_id or sys_kb_id from the url which will not work if we replace it with sysparm_article.

Can somebody please give their suggestion on this ?Should we proceed as we are in custom application and what could be the minimum changes that can be done to avoid any major mess?

Below is the link that I have gone through but it is for New York .

Set service portal default KB URL to permalink - ServiceNow Community

Thanks,

Harsha

[kaushal_snow · Accepted solution]

@Harsha34 ,

You can replace the default sys_kb_id URL with a permalink using sysparm_article, but since many oob widgets and script includes expect sys_kb_id you’ll need to clone or override the widget that opens the KB article (or the UI Macro) and change the link generation to use sysparm_article=KBXXXXX (using the article number from the record) instead of sys_kb_id, and thoroughly test all functions that rely on sys_kb_id to ensure they still work.

Just be cautious: changing the URL may break parts of the UI, scripts or metadata retrieval that depend on sys_kb_id, so make minimal changes, scope them carefully, and validate features like related articles, breadcrumb, versioning, and backend scripting...

If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.

[Harsha34]

Hi Kaushal,

Thanks. This was helpful.

Regards,

Harsha

[donna567]

---

@Harsha34 wrote:

Hi,

I work on a custom application and we use a custom service portal. The portal has lots of widgets and buttons int it and end users are using it currently. 

When we click on KB Category Tree and select one article and click on it then it opens with the url . This is how it works OOB as well.

?id=kb_article_view&sys_kb_id=8b4b9fbb3bff285y72b466a985e45a87&kb_category=25546ec197290e102e00bdb8c253af6f

When we permalink this article and open in anew tab the below url opens:(OOB)

?id=kb_article_view&sysparm_article=KI447####

Requirement is to replace sys_kb_id URL with Permalink URL.

I understand that they would be always able to see the latest version by doing this. But I am afraid doing this can break several other functionalities that are running at the backend although we have set this up in the widgets that they should show up in a similar way on permalink as well, but there are OOB script includes inside these which is using sys_id or sys_kb_id from the url which will not work if we replace it with sysparm_article.

Can somebody please give their suggestion on this ?Should we proceed as we are in custom application and what could be the minimum changes that can be done to avoid any major mess?

Below is the link that I have gone through but it is for New York .

Set service portal default KB URL to permalink - ServiceNow Community

Thanks,

Harsha

---

Hello @Harsha34,
If your custom widgets and backend logic rely on `sys_kb_id`, switching to `sysparm_article` (permalink) may break OOB script includes and data resolution. Since you're in a custom app, you *can* proceed—but only after ensuring all dependent widgets and scripts are updated to resolve `sysparm_article` to `sys_kb_id` internally (e.g., via a GlideRecord lookup). This minimizes disruption while supporting permalink usage. Test thoroughly in subprod before rollout.

Best Regards,
Donna Taylor