One of the nice features of Service Portal is the sheer number of widgets that are included by default after activating the plugins. In today's AISP (yep, I acronymed it) post I'm going to explore one of those widgets a bit. The Form Widget.
One of the most common questions I used to see around CMS was something like: "How do I open this record in CMS?" There were a couple of different ways to do it with content types and detail records, a static iframe, or with a little bit of work a more dynamic iframe that would take in url parameters and render some content. Each of these methods had some drawbacks and I was never quite satisfied with both the learning curve and the result. Oh, and they all used iframes.
With the form widget it's easy to display any record in ServiceNow within your Service Portal without doing any configuration, all you need to do is link to it. Lets take a look at the self-service view of an incident form in the standard view of ServiceNow:
We know that this form has a url that looks something like:
Without doing anything other than making sure that the Service Portal plugins are enabled, I can show this same record in my Service Portal using this url:
https://instance.service-now.com/sp?id=form&table=incident&sys_id=b28a474f4fb8220067d9b5e18110c758&view=ess
The form widget is on a page already by default that can be called in any service portal called form. You're then able to pass the page the following url parameters:
- table - the name of the ServiceNow table where the record is located
- sys_id - the unique identifier of the record
- view - an optional parameter where you can specify which view the fields are pulled from
- query - allows you to specify a query
If you want to include this widget on another page, you also have some widget options you can set:
- Disable UI Actions on Form
- Display current form view
- Omit header options icon
You may have noticed that by default the form widget includes ui actions, all fields and related lists on the form view, and also client scripts and ui policies. However, there are some exceptions to those. They are documented here, but I'll list them out:
- Client side ui actions
- Anything that uses jelly, including
- UI Macros
- UI Pages/Formatters
- Client Scripts where Run scripts in ui type is Desktop
In addition to those, there are a number of different client side scripting techniques and methods that are not supported. All of the Service Portal supported objects and methods are listed in the github doc below, and these are not limited to the form widget.
Service Portal and client scripts
Previous blogs in this series:
30 Comments
