It makes sense that break could end up being some kind of reserved term given its use generally inside of Java and Javascript.įor now, use in your workflow at your own risk. We will only need to maintain this single script instead of 4 different ones: This works on Service Portal and Platform UI. I’ve done some checking to try and see if that is documented somewhere, but haven’t be able to find anything to date. First let’s create simple onChange client scripts for fields 1 to 4 with identical script: You see it calls populateField5 () function which is stored on gscratchpad. It’s possible that something else was happening as a result of setting the break variable to true, but as nearly as I can tell, doing that actually dumped the values in the scratchpad, leaving me with undefined instead. I wrote the code, and when the workflow detected that it had gotten to the point where the loop wasn’t supposed to continue, I set “ = true”, at which point my workflow broke and started behaving erratically. That would save me having to do a GlideRecord query at the decision point to determine whether or not it was time to exit the loop.
This KB will also explain the changes made in Madrid release.
#SERVICENOW SCRATCHPAD HOW TO#
Given that, it seemed sensible to to use the scratchpad to set a variable that I could then check against when it came time to break out of the loop. This KB will demonstrate how to process the output of Query AD activity, and store a property from the output as a workflow scratchpad variable. This KB will demonstrate how to process the output of Query AD activity, and store a property from the output as a workflow scratchpad variable. Here is also a good summary about variables in a workflow.I recently had a project where I wanted to use a looping workflow that would continue around the loop until some criteria was met.įor various reasons, I was going to find out whether or not a given loop was done before I actually reached the if statement that was designed to break the execution flow out of the loop and allow the workflow to move on. ( Attention! it is the column name, I need to use!) Within the subflow I then can get the value of the input variable with this command: Instead you should use gscratchpad or the asynchronous GlideAjax. I give the value from the scratchpad variable to this input variable of the subflow by entering $. It is important to minimize server calls, especially you should NOT use a direct GlideRecord lookup nor a gform.getReference () (if you use the getReference (), remember to use a callback). When I now open the subflow activity in the parent workflow (where I call the subflow), then the devicename_task field is shown. I checkout the subflow (Change Request – System Build Tasks), went to Properties > Edit Inputs and created this input: Now I need to have an input variable in the subflow. Edit the Alert for VIP client script again to take advantage of this data. Now I have the name of the device in the scratchpad variable devicename of the parent workflow (Change Request – System Build).Īs scratchpad variables are only available in the context of the workflow it is running in, I cannot use this variable in the subflow. ServiceNow: Building Powerful Workflows by Tim Woodruff, Ashish Rudra Srivastava, Martin Wood Using scratchpad on the client The gscratchpad object is reconstructed on the client side as a global variable. =current.short_description.split(‘:’).trim() I have used the scratchpad to store the extracted value. I have no field in the change request, where the device name is entered separately, therefore I had to extract it from the description. Child: Change Request – System Build Tasks.Catalog item workflows use variables defined in the form and do not display the inputs tab in the workflow properties.Īs I struggled with the documentation from ServiceNow about these input variables, I wanted share an example how I used an input. Workflow inputs are only available in workflows which are not used for Catalog items (using the table Requested Item = sc_req_item). A workflow input is a string variable, which can be defined within a child workflow and to transfer data from a parent workflow.Īn input can be necessary, if a value, which was created within the parent workflow, needs to be used within the sub workflow and no existing form field could be used to write that value to.
0 kommentar(er)
