icerge

Approval types

Requirement justification

We had a very similar requirement due to the multiple number of different approvals needed for our Change process to be able to display an Approval Type to our approvals. We were able to accomplish this by performing the following configurations:

Technical design

1. Add a column to the Approval table [sysapproval_approval]. For our solution we simply added a Choice type column called Approval Type [u_type]. We then created the choices we needed in the Choices related list.
2. Next we modified the Workflow Activity Definitions for each of the Approval Workflow Activities. You can find these by searching for Workflow Activity Definitions in the navigator. For example, open the Approval - User definition record. Scroll down to the Activity Variables tab and click the New button to add a new variable. This will seem very familiar if you have created Catalog variables. For our solution our variable was created with the following attributes:

• Column name = u_appr

icerge

Global UI Scripts

It is an eval from BP perspective and HS doesn't like it either.

I found two basic mistakes in configurations.

As Source file for JS Include

You put a shared code or a 3rd party lib to UI Script and include it to a widget. Global checkbox is redundant. Any UI Script will be loaded.

As shared lib for form client side scripts

Yea, good motivation, avoid code duplication. Any shared functionality can be put to UI script and loaded in client side

icerge

gs.action

gs.action.getGlideURI().get('parameter_name');

Another longer alternative:

gs.action.getGlideURI().getMap().get('sysparm_query');

icerge

Ajax calls from Native forms and Catalog items

Client script + UI Script + Script Include (Ajax) + Script Include (API)

Client script is a calling side. Optionally, it may be wrapped into a UI Script to form re-usable Client side API.

Script Include (Ajax) is an interface for client side interactions it fetches parameters, validate them and call necessary APIs.

Script Include (API) implements server side functionalities that may and most probably will be used by both Client and Server side logic. No Ajax parameters are available in context, they are supplied as method arguments.

Naming convention