Understanding Scratchpad Part 2 (Workflow)

Yesterday I wrote about the g_scratchpad object and what it’s used for. Today is about a different scratchpad, the workflow scratchpad. I started yesterday by explaining the scratchpad is for sharing data between different areas. It’s a lightweight way to store and share data. In the workflow, each activity is an individual container of functionality. They have no direct relationship with any of the other activities in the workflow, instead they are all connected via a parent workflow context record and also connected by the fact that the activities are all running against the same ServiceNow record. For the most part, that is absolutely fine, all activities are unique containers and don’t need details of the previous activity to be able to do what they need. But what if the activity required some information from a previous activity to do its job? Well this is where the workflow scratchpad comes in to play.

Using this functionality is extremely easy, in a script you just set the values you want in a global object already created for you like this:

workflow.scratchpad.myCustomKey = 'My Random Data';

That’s it, the value is stored. And then when you want to access this from another activity, you just retrieve the data as you would any other object:

var myData = workflow.scratchpad.myCustomKey;

It’s very standard stuff when working with objects as the object is stored in memory. The memory keeps hold of the object and allows it to be read and written at ease. However they all run in the same session and therefore access the same memory. With activities however, each activity can run in different sessions, on different nodes, by different users, weeks apart even! This begs the question, where is the data stored if not in memory?

Right at the beginning I mentioned that the only two connections between activities is the parent workflow context record and the record they are running against.

It clearly won’t be stored on the record otherwise there would need to be an additional field on every table which you run workflows on. This leaves us with one more option which is the workflow context (wf_context) record. And indeed if you go to this record, you’ll find a field called ‘scratchpad’ which does nothing but stores a JSON string of the object you’ve created. The next time a workflow activity runs, ServiceNow will automatically parse this JSON string and add it back to the workflow.scratchpad variable ready for you to read the values or modify the details. That’s all there is to it, the magic of the workflow scratchpad exposed.

Useful if you want to debug that you’re storing the correct data. Also useful if you have two separate workflows and want to access the scratchpad of the other.


  1. I’m curious about the last line “Also useful if you have two separate workflows and want to access the scratchpad of the other.”

    Is this referencing to a sub-workflow, or an entirely different workflow?

    I’m assuming a sub-workflow, since it probably shares the context?



    • Technically any workflow. All you need to do is a GlideRecord in a script activity to the workflow context table (with the whatever query you want), find the context you’re interested in and read the scratchpad field. You can then use the JSON script include or native JSON object depending on your SN version to turn it into an object to read the values from. To be fair, I’ve only ever had to do this once but as with everything, I find it’s good to have in your back pocket


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.