How to create a button to link to an interceptor page

[Steve42]

I need to create a form button that will allow go to a URI within servicenow actually it's an interceptor.  It's the same interceptor that when you are on a company record and see the open recent cases you can click new button.  Since I can not put the Open Recent cases on the other form (it's built off the task table and is already used by the companies form.  I just need to put a button that will do the same thing.  I know it will be a UI Action but not sure how to do the script for it to a URI. Could someone lend a hand with this?

[johnfeist · Accepted solution]

Hi Steve,

You are correct about using a UI Action.  I built this for an example that takes you from an incident to the Change request interceptor.  The "gotcha" comes in getting the URI.  Here's the script part of my UI Action

gs.setRedirect("/wizard_view.do?sysparm_wizardAction=sysverb_new&sysparm_stack=change_request_list.do&sysparm_parent=8db4a378c611227401b96457a060e0f4&sys_target=change_request");

The "trick" is to go to the interceptor page and capture the URL.  From there trim the front so that you get to the uri section.  Then you need to convert the HTML character codes into their actual characters (e.g. %3D is =).  Here's the link to a page with those translations.

Hope that helps.

:{)

Helpful and Correct tags are appreciated and help others to find information faster

[etabalon]

Hi johnfeist,

This code was very helpful and it works. My scenario was from a problem ticket creating a change from a UI Action. 

What I want to do next is after creating the change, I want to populate the problem.rfc field with the change ticket number.

The problem was once we redirect, we lost track of the previous page.

Do you have an idea if this is doable?

Thank you!

Enrique

[johnfeist]

Hi Enrique,

I needed to something like that moving an incident to a request.  In the URI, the parent sysparm is the sys_id of the source object, in your case the problem.  You do have the ability to add scripting to the interceptor(s) which should let you craft the Target URL to include the parent value that was passed in.  From there, you can have a Before Insert BR take care of populating rfc and any other fields.

The potential gotcha you have with that is if you want to use the methodology for more than problems.  In that case, your BR would need to do a look up on task to find out what type of object the parent is (task_type) and from there populate rfc.  rfc is not a task level property.

Being a strong subscriber to the lazy programmer theory, what I did was set up the UI action to directly create a change of the strictest type (we don't use the OOTB change types).  In that scenario, the code knows both objects (problem and change) so populating rfc is easy.  Let me know if you want that code.

The rationale I employed is that if the person creating the change wants it to be of another type, it is easy enough to change that while the change is New.  The other benefit is that populating change fields from the problem, incident, etc. is really simple.

Hope that helps.

:{)

Helpful and Correct tags are appreciated and help others to find information faster

[etabalon]

hi johnfeist,

Thanks for the quick response. If you could share your code that would be greatly appreciated. 

Our target behavior is same user experience whether the user is creating a change from as a standalone (by itself) or when it's coming from a problem, incidents or requests. OOB is creates the change ticket from a problem without getting that user input of what change type they want to create.

Have a great day!