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