Troubleshooting the Workflow Scratchpad | Diagnosing missing or unexpected valuesIssue The workflow scratchpad is used to store data during the execution of a workflow. Values in the scratchpad can be set and/or accessed by any activity in the workflow. Viewing the scratchpad for executing workflow context In the main ServiceNow window, select the Active Context module from the Workflow application.Select the executing workflow context that is being investigated to open the Workflow Context form.If the Scratch pad field is not visible, personalize the form layout and add the field to the form.The field displays a JSON serialization of the scratchpad contents. Note: For large scratchpads, the serialized JSON data can be difficult to read. Cut and paste the contents of the field into an online JSON parser (for example, http://json.parser.online.fr) to get a navigable tree view of the data. Logging the workflow scratchpad in the workflow log It is often useful to view the contents of the scratchpad and specific steps in the workflow. Manually viewing the context form at those times would be difficult or impossible. However, it is easier to log the scratchpad contents by either adding a log activity or inserting a line of script into a script block in an existing activity. Then, view the context log later to see if the scratchpad as it existed at those points in time. Logging the scratchpad with a log activity Drag a log activity from the activity tree on to any transition in the workflow. On the Activity form that opens, enter a unique name for the activity and the line below for the message:at ${activity.name} the scratchpad is ${workflow.scratchpad} Logging the scratchpad from the script block of an existing activity Add the line below to the beginning of a script block of an existing activity to log the scratchpad contents: workflow.info('at ' + activity.name + ' the scratchpad is '+ new JSON().encode(workflow.scratchpad)); Determining if the workflow is encountering scratchpad data issues If there are missing or changed values in the workflow scratchpad, use the techniques above to log scratchpad contents at relevant points in the affected workflow and isolate where the scratchpad data is changing unexpectedly. Understanding where the data is being changed may help identify flaws in the workflow logic. If that does not explain why the scratchpad data is changing, these issues below may be causing the problem. Large scratchpad data is truncated The scratchpad is limited to 8,000 characters and is truncated when it hits that limit. This can be verified either by viewing the scratchpad in the executing context form or by logging the scratchpad. Solution(s): It is possible to increase this limit by personalizing the dictionary entry on the wf_context.scratchpad field. However, redesigning the workflow is the recommended solution. The scratchpad is intended to hold only the transient data needed while a workflow is executing. Data that is intended to be stored permanently should be moved into other records as soon as possible. Scratchpad is missing data or contains unexpected values Prior to the Dublin release, it was possible for a multi-branch workflow to execute two activities at the same time, causing any scratchpad modifications made by one of the activities to be overwritten by the other. The problem can be verified by checking the Activity Indexes for the affected workflow contexts. On the Context form, find the Activity History related list. If the Activity Index column is not visible, personalize the list and add it. Sort by the Activity Index. If there are two activities with the same index value, the workflow is experiencing this problem. Solution(s): Upgrade to the Dublin release.Make the workflow more serial. The problem can only occur when a multi-branch workflow is executing different transition paths at the same time. Redesign the workflow to have fewer branches by consolidating them into a single transition path. Scratchpad is missing data or contains unexpected values Modifying the workflow context while the workflow is executing may cause scratchpad data loss. This can occur when viewing the context record while the workflow is executing, and then clicking the Update button. Any changes that the executing workflow have made to the scratchpad are overwritten by what was in the scratchpad when the form loaded. This problem can be investigated by looking at the Updated and Updated by fields on the workflow context record and looking for unexpected values. Solution(s): It should almost never be necessary to use the Update button on the workflow context form. In the Eureka release, the Update button has been removed. Educate any users that have rights to view that form. Consider adding an ACL to restrict update access on the wf_context table.It is possible that a custom business rule or some other custom script is updating the context record and/or the scratchpad unexpectedly. This is a bad practice and strongly discouraged. Only the workflow engine should be modifying the workflow context record. If experiencing this problem, turn on Business Rule Debugging to help identify what business rule is causing the problem. Redesign the script so that it does not need to modify the workflow context. Scratchpad is missing data or contains unexpected values Users can accidentally start multiple workflow contexts by repeating a UI action, such as clicking a Submit button multiple times. When this occurs, it may appear as though some scratchpad data was lost. This problem can usually be verified by checking the All Contexts list of the workflow application. In most cases, several contexts of the same workflow start up in a very short period of time. It is also possible for this problem to occur over longer periods of time. This is more difficult to identify. Look for multiple contexts of the same workflow executing against the same current record. Comparing the context start time against when the user thinks the workflow started is also useful. Solution(s): Educate users.Modify the workflow so that it returns control to the user sooner. When a user starts a workflow, it will execute on the user's thread until all transition paths of the flow are in a wait state (waiting on an Approval, Task, Timer, Orchestration activity, etc). At that point, control should return to the user. Try redesigning the flow so that the time-consuming work happens after control is returned to the user.Modify the UI action so that it starts the workflow asynchronously (usually through a client-side Ajax request), returning control to the user sooner.