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.