One of the things I love the most about being a Technical Consultant with ServiceNow is being exposed to so many different customers and varying requirements, and occasionally one just sticks in your head and takes on a life of its own!
We recently received an interesting ask from a customer - they were conscious that their end users may be able to see personal or confidential information attached to a record in ServiceNow, and wanted their helpdesk users to accept a warning that they should not attach private information before being allowed to attach files to a record.
This piqued my interest, as having worked with healthcare companies and on HR projects in the past, I’m very aware of the liability this could potentially cause for a company. I also thought the challenge might be fun! So, I decided to put together a proof of concept for this requirement, and then expanded upon it as a personal project. I wanted to test my skills to try and make the solution as elegant and as simple as possible.
I wanted this mini project to have three main attributes: it should be extensible, customisable and (most of all) easy to use!
What Does It Do?
The experience from a Service Desk user standpoint is very simple. The attachments icon (the paperclip) isn’t available until a button is clicked to enable attachments. Then, a confirmation box pops up, and on acceptance, the attachments button is made available.
If the user clicks “Cancel” on the dialog box, nothing happens. When the page is reloaded, the warning must be accepted again.
With this update set come three system properties for maximum configuration of the functionality without any coding whatsoever.
|I want to…||Solution|
|Turn off the functionality.||Remove all table names from the “ufi.attachment_confirmation.tables” system property, so it is completely empty.|
|Add the functionality to a table.||Add the table name to the comma-separated list in the “ufi.attachment_confirmation.tables” system property.|
|Remove the functionality from a table.||Remove the table name to the comma-separated list in the “ufi.attachment_confirmation.tables” system property. (I bet you didn’t see that solution coming…)|
|Allow only admin users to be able to attach without a warning.||Set the value of the “ufi.attachmentconfirmation.overrideroles” system property to be “admin”.|
|Enable the functionality for all users (including admin).||Ensure the “ufi.attachmentconfirmation.overrideroles” system property is empty.|
|Change the label of the button.||Change the Name field of the UI Action (by default called “Enable Attachments”). See Figure 2.|
|Change the button from a form button to a related link (or other type of UI Action).||Untick the “Form button” box on the UI Action, and instead tick the “Form link” box (or whatever you like). See Figure 3.|
|Change the wording of the confirmation message.||Change the value of the “ufi.attachment_confirmation.text” system property to whatever you’d like. See Figure 4.|
How It Works
On a technical level, this solution is really quite simple! There are only a few components:
The three system properties discussed above,
A Display Business Rule to grab those property values from the server,
A client script which disables the attachment button if needed (based on the Override Roles and Tables properties),
The UI action itself,
And a Script Include to ensure the UI action shows or hides as needed (again based on the Override Roles and Tables properties).
When a user loads a form, the first thing the system does is check the applicable System Properties, grabs the values, and stores them in g_scratchpad so the client can access them later. (I like to imagine a little ServiceNow elf dashing over to a file cabinet and frantically scribbling down the values in a notepad, but maybe that’s just me…)
Then, the client script runs. It checks g_scratchpad for the tables that the functionality should run on, and compares it with the current table name. If the current table isn’t in that list, then nothing happens. If it is, the next step is to check the override roles. If the user has one of the roles listed in the Override Roles system property, or if the list of override roles is empty, then attachments are disabled. (This is done with a handy client-side g_form function called disableAttachments(). It also has a sister function, enableAttachments(), used later. A prize for you if you can guess what that does.)
At the same time, ServiceNow runs through the UI Action condition to check if it should be displayed (it uses a supplementary Script Include for this, so the UI Action condition isn’t a million characters long). It basically does the same thing as the client script does, but checks it from the server side. To help with this, the current record and the current user are passed through to the script include from the UI Action.
Finally, when the button is clicked, the UI Action runs its script. It’s entirely client-side, and it shows the confirmation message (previously stored on the scratchpad from the system property), and if the user accepts, enables attachments (using the aforementioned enableAttachments() function).
This functionality went through a couple of iterations, so I’d like to say a big thank you to my fantastic colleagues at Unifii who helped me with the idea, testing and gave me some amazing feedback on this – particularly Mitch, Shlomo, Michelle, and Daniel.
If you’re interested in this functionality in your ServiceNow instance, contact us here, we would love to help!