0

Customise your UI Action Button or Navigation Bar of your forms 0 (0)

This onLoad client script shows how to change the background color of form buttons in ServiceNow. For this example, I set up the script to change the color of the ‘Approve and ‘Reject’ buttons on the approval form to green and red respectively. The script itself is pretty straight-forward and can be used as a model for targeting other DOM elements using client-side JavaScript.

function onLoad() {
   //Change the color of the 'Approve' button to green
   changeButtonColor('approve', '#00CC00');
   //Change the color of the 'Reject' button to red
   changeButtonColor('reject', '#CC0000');
}

function changeButtonColor(buttonID, backgroundColor) {
   try{
      //Find the button(s) by ID and change the background color
      $$('button[id=' + buttonID + ']').each(function(elmt) {
         elmt.style.backgroundColor = backgroundColor;
         elmt.style.color = '#ffffff'; //make the button text white
      });
   }catch(e){}
}

If you want to take this step a little bit further, you can add icons to UI actions.
Fortunately, with the addition of a new icon set in recent ServiceNow releases, this has become pretty simple to do.

image

The following script can be used in any standard form client script. The key is the ‘transformButton’ function at the bottom. This could be included as a global UI script in your instance so that you don’t need to include it in every single client script. Once that’s in place (whether in a global UI script or in the client script itself) you can just call ‘transformButton’ with the appropriate parameters to change the button however you want. The parameters used are as follows…

  1. UI action name (Mandatory)
  2. Button background color (Optional)
  3. Button text color (Optional)
  4. Button icon name (Optional)
function onLoad() {
    //Change the color of the 'Approve' button to green
    transformButton('approve', '#77FF77', 'white', 'icon-success-circle');
    //Change the color of the 'Reject' button to red
    transformButton('reject', '#FF0022', 'white', 'icon-error-circle');
    //Change the color of the 'Info' button to blue
    transformButton('info_button', '#31708f', 'white', 'icon-info');
    //Change the color of the 'Warning' button to yellow
    transformButton('warning_button', '#f0ad4e', 'white', 'icon-warning-circle');
}

function transformButton(buttonID, buttonBackgroundColor, buttonTextColor, buttonIconName) {
    try{
        //Find the button(s) by ID and change the background color
        $$('button[id=' + buttonID + ']').each(function(elmt) {
            elmt.style.backgroundColor = buttonBackgroundColor;
            if(buttonTextColor){
                elmt.style.color = buttonTextColor;
            }
            if(buttonIconName){
                elmt.addClassName(buttonIconName);
                //Add some spacing between the icon and button label
                elmt.innerHTML = ' ' + elmt.innerHTML;
            }
        });
    }catch(e){}
}

This same idea can be applied to form header colors as well by getting the HTML element of the form. You’re probably aware that ServiceNow provides a global CSS property to set the form and list header color. The global property can be found by navigating to System Properties -> CSS, and changing the ‘Banner and list caption background-color property.

function onLoad() {
   //Change the color of all form section headers
   var backgroundColor = 'red';
   $$('.navbar').each(function(elmt) {
      elmt.style.backgroundColor = backgroundColor;
   });
}
 (All credits go to ServiceNowGuru for this awesome finding!)

[Updated 30/09/2019]

As you may notice, the UI action element names differ (top from bottom) and for this, you need to add them also – you can verify the names by getting the HTML element of the form. (tested in Madrid)

function onLoad() {

changeButtonColor('approve', 'limegreen', 'white'); //approve button header
changeButtonColor('reject', 'red', 'white'); //reject button header
changeButtonColor('approve_bottom', 'limegreen', 'white'); //approve button bottom
changeButtonColor('reject_bottom', 'red', 'white'); //reject button bottom
}

function transformButton(buttonID, buttonBackgroundColor, buttonTextColor, buttonIconName) {
    try{
        //Find the button(s) by ID and change the background color
        $$('button[id=' + buttonID + ']').each(function(elmt) {
            elmt.style.backgroundColor = buttonBackgroundColor;
            if(buttonTextColor){
                elmt.style.color = buttonTextColor;
            }
            if(buttonIconName){
                elmt.addClassName(buttonIconName);
                //Add some spacing between the icon and button label
                elmt.innerHTML = ' ' + elmt.innerHTML;
            }
        });
    }catch(e){}
}

You can now change the colour by picking a form style.

I hope this helps.

0

Design a Powerful and Scalable Workflow with System Properties 0 (0)

The article below is intended for any person customise your Workflows. Javascript knowledge is useful but not required.

As I mentioned in other articles, regardless of your task, there aren’t always enough hours in the day to get everything done. As a result, you constantly feel like you’re always behind. And that’s just not good for your productivity or your health. Instead of putting in those extra hours, you can become more effective at work by focusing on what really matters. And you can get started with that ASAP by applying this quick scalable solution to your scripts. 



Here’s a few things we will cover:

Use CaseExample
Automate properties (sys_properties)System properties store configuration information that rarely or never changes. Each time you change or add a system property, the system flushes the cache to keep all nodes in the cluster in synch. This cache flush has a very high performance cost for one to 10 minutes, which can potentially cause an outage if done excessively. To prevent such outages, do not use a system property to store configuration information that changes more than once or twice a month. I usually identify what can change in the future, like “group id”, “names”, etc.

Use Case Walkthrough

  1. In the Navigation filter, enter sys_properties.list.The entire list of properties in the System Properties [sys_properties] table appears.
  2. Verify that the property does not exist by searching for the property name.
  3. Click New.
    Usually I use “company.workflow.default.L1″.
  4. Complete the System Property form.
    Type: String
    Value: <sys_user_group_id>
  5. Navigate to Workflow > Workflow Editor
  6. Edit your workflow and change script as appropriate.

Script
gs.getProperty(‘company.workflow.default.L1′);

Unfortunately there is no magic formula to identify which task or script or variable should be considered as system properties but to start you should think what can change over the time. 

Example #1:

Found some quite simple use case in the communities (link). A user would like to add a IF condition in the workflow to verify if the sys_property value is equal to true and then, the requester assigned will be XXX company and eventually will fire the next sc task. 

answer = ifScript();

function ifScript() {
    var prop = gs.getProperty('ab.provision.workflow');
    var comp = current.u_requestor.company.getDisplayValue(); //I am assuming u_requestor is the field company name

    if (prop == 'true' && comp == 'company name') {
        return 'yes';
    }
    return 'no';
}

Conclusion

System properties are not limited to just Notifications or Workflows, they’re part of the NOW Platform and can include anything we have in the Platform. Try to automate your instance and try to centralize all your “customer” data in one place. Use all the tools at your disposal to make that happen.

I will try to collect a use case for each type in order to help you to identify on which cases you should apply the sys property technique.