A Day in Paris Series: En Route to a Standard Ticket Page

[JennyHu]

Paris is the Capital of Fashion. Its style is simple, and nothing extravagant. In this A Day in Paris series, I take you to a UX improvement in Paris that offers consistent layout and flexible configuration options. This feature will make Service Portal developers and designers happy!

It's a new Service Portal feature called Standard Ticket Page. 

If you have different request types on your instance and are struggling to provide a consistent ticket page while showing request-specific information, this feature is for you.

Before Paris, the Out of Box (OOB) ticket page looks like the screenshot below. As you can see, the ticket details are shown on the right. There's a lot of text, and it appears cluttered. The Ticket Fields widget specifically gets the number, state, priority, sys_created_on fields in the Server Script, which means it's not configurable. If your custom request does not require all the details, you may have cloned the Ticket Fields widget, and created a custom Ticket Fields widget to customize the display.  Imagine having many different request types; customizations would be a pain to maintain!  On the other extreme, imagine telling all your stakeholders, you shall only display these standard fields even if they are irrelevant to your request type.  How would they feel?

Standard Ticket Page brings you a happy medium where we will be configuring not customizing.

With the Standard Ticket Route is activated, the ticket page is routed to a new page (standard_ticket). The new layout is clean that looks like this:

It comes with fantastic configuration options.  You can create a Standard Ticket Configuration record for any task-extended table.

What you can configure:

• Header Region - If your request doesn't use the State field, you can set to use any other field of the task-extended table.
• Info Region - Here, you can define the table fields to show. For example, if urgency is not a field that is relevant to your request type, you can choose not to include it in the Info Region.  To take it a step further, you can select a widget to display in the info region.  Or, you can choose to show nothing at all.
• Action Region  - Here, you can specify an action widget for the ticket.  OOB, Paris provides an "Incident Standard Ticket Actions" widget that lets users resolve, reopen, or close an incident ticket based on business logic defined in IncidentUtilsSNC Script Include. For other request types, you will need to create a custom service portal widget.  Or, leave this region blank, meaning users do not need to take any action on the ticket.
• Tabs - The tabs are entirely configurable. You can remove Activity, Attachments tabs, and add other tabs such as Variable Editor, Variable Summarizer, or even a custom widget.

The following screenshot shows a proof of concept of how you can configure the regions for a custom request.  For an absence declaration, for example, I have shown only the relevant custom fields, namely, Date of Absence and Reason in the Info Region.  I took out the Attachments tab and left the Action Region empty. 

Overall, I'm quite pleased with this feature, for the double C (consistency and highly configurable)!  Would you call this a Coco Chanel? 😛

That's it for now, and I will let you explore the Standard Ticket Page.  

Disclaimer:  The exploration is based on the Paris EA.  The features may change when Paris is officially released in Q3 2020.

Check out my other post in A Day in Paris Series:

• A Day in Paris Series:  Exploring Delegated Request Experience

[AG - LearnNGrow]

Thanks for clarification. But unfortunate i am not able to configure TAB option. I am following the same steps but still Tabs are not coming as expected for me. Could you please guide me.

[JennyHu]

Hi Atul,

Which part is not working for you?  You mean you can configure tabs, but they don't show up correctly on the service portal page? 

[Megha C1]

@Jenny Hu , 

I have upgraded my instance on paris but i dont see mentioned User interface, Do we need to configure anything else?

Thanks

[JennyHu]

Hi Megha, 

According to the doc, if you upgraded your instance, you would need to activate the page route map for the standard ticket page.  Have you tried that?

https://docs.servicenow.com/bundle/paris-servicenow-platform/page/build/service-portal/task/config-p...

[AbhishekGardade]

You can refer the docs as Jenny said or I have mentioned steps in my blog.

https://community.servicenow.com/community?id=community_blog&sys_id=ac49dca9dbde9c90fa192183ca9619cc

Thank You,

Abhishek Gardade

[brianmelvin]

The Number, Created, Updated, and State fields are displaying oddly for us - the white background isn't proportional.

Our portal theme is set to a background color of #EBEBEB and a panel background is white. The new standard_ticket header doesn't appear to be handling this correctly. 

Is there a way to correct this without cloning the widget and correcting the HTML/CSS? 

[brianmelvin]

Solved - by adding the following CSS to the instance that contains the Standard Ticket Header on the standard_ticket page:

.form-control.no-padder.no-border {
	background-color: #EBEBEB;
}

[Community Alums]

I have added the close_notes field to the info region, but when the text is too long, it cannot be seen, even with the mouse-over, which only opens upwards (cannot se the top).

If e.g. links are added in the close_notes, the text seems to continue outside the mouse-over area.

New lines are ignored in the mouse over area, and in the description (show more), making it quite ugly sometimes.

I tried to add the "Ticket Fields" widget to a tab, to solve the problem (the user cannot see all the resolution notes), but that does not work:

Does anybody have a work-around for this?

[JennyHu]

Hi Ingrid,

You will need to create a custom widget to display custom tab content. The Ticket Fields widget won't work. If you look at where that widget is used, it's used on the ticket page, and it includes more than you need. I've created a sample proof-of-concept widget code below you can try.

With this widget, for the Widget parameters, add a name-value pair:

• In the name input box, enter field. 
• In the value input box, enter the name of the field.  In your case, enter close_notes. 

The widget parameters are nice. You can pass in parameters without having to hardcode specific values in your widget code. This widget has the flexibility to show other fields, and you can expand the code to loop through a list of fields to display.

HTML

<dl>
  <dt>{{::c.data.fieldLabel}}:</dt>
  <dd>{{::c.data.fieldValue}}</dd>
</dl>

Client Script

function() {	
  var c = this;	
}

Server Script

(function() {
  data.sys_id = $sp.getParameter("sys_id");
  data.table  = $sp.getParameter("table");
  data.field  = options.field;

  var gr = new GlideRecord(data.table);
  if (!gr.isValid())
	  return;
  if (!gr.get(data.sys_id))
    return;

  data.fieldLabel = gr[data.field].getLabel();
  data.fieldValue = gr.getValue(data.field);
	
})();

Hope this helps!

[Community Alums]

It helps a lot.

Thank you so much.

[Jesper Slot]

Is there any way to create a link to a specific tab?

If you created a Resolution tab with the resolution note and maybe a link for the survey, could you then with the email notifications direct the user directly to that Resolution tab on the new standard ticket page?

[Jayesh Mohan]

This is a great post about the new standard ticket page. @Jenny Hu  I am trying this out in our sub-prod and I am experiencing an issue  with the RITM records. We want to display the 'Stage' field, but it looks like the standard ticket page does not have a way for the stage field to be expanded always. We are able to expand this in our current RITM ticket status page as it allows for widget options. Is there a way to configure this without cloning the OOB widget?

[JennyHu]

Hi @Jayesh Mohan,

I'm thinking you may need to clone the OOB Standard Ticket Header widget to achieve this.  Looking at the code of this widget, it calls an embedded widget: Request Item Workflow Stages.  Though, it doesn't look like it's passing in any instance options other than the req_item_id.

If you look at the Request Item Workflow Stages widget, there is a boolean option that allows you to set expand to true (it defaults to false).

To pass in the options for the embedded widget, check out this doc site Embedded widgets.

Hope this helps!

[Jayesh Mohan]

Thank you for your response Jenny

[Ed Hefford]

ooh, how did you get the Close Notes tab to work? I'm looking to implement that right now and could use a pointer.

Thanks, Ed

[KyleB]

Seriously, this is fantastic. You've just helped me solve a use case, while providing a simple custom widget for me to get my head around and learn something (I have limited experience of custom widgets). 

The next challenge for me is to see if I can find a way of showing associated Task SLAs...

[JennyHu]

Thank you for your comments @KyleB! Glad this was helpful to you. Good luck on your next challenge!