While this article is still extremely useful as an example and a reference for exporting records and use of processors, the specific functionality for exporting workflow versions is now included by default in ServiceNow. The functionality was built-in starting with the Aspen release.

I‘ve written before about how you can quckly export and import data between ServiceNow instances using the XML export/import context menus. While this works great for a lot of situations, it doesn’t work so great for data that resides in multiple tables, but really makes sense to be exported as a single unit. One example of this is Graphical Workflows. The components that make up a Graphical Workflow version are actually stored in 7 separate tables. It is possible to export a graphical workflow version but you have to do 7 separate exports to do it! In this post, I’ll show you how you can set up UI actions for some of these more complex export tasks.


The first step is to set up a ‘Processor’ record to handle the export. ServiceNow actually has some built-in code to handle exports like this. You just have to know how to leverage it. Here’s how you would set up a processor for the workflow export.

‘ExportWorkflow’ Processor
Name: ExportWorkflow
Type: Script
Path: export_workflow
Script:

//Get the sys_id of the workflow version
var sysID = g_request.getParameter('sysparm_sys_id');
//Get the sys_id of the workflow
var wfID = g_request.getParameter('sysparm_wf_id');
var actID = '';//Query for workflow activities
var act = new GlideRecord('wf_activity');
act.addQuery('workflow_version', sysID);
act.query();
while(act.next()){
actID = actID + ',' + act.sys_id.toString();
}

//Export workflow version info to XML
var exporter = new ExportWithRelatedLists('wf_workflow_version', sysID);
exporter.addRelatedList('wf_stage', 'workflow_version');
exporter.addRelatedList('wf_activity', 'workflow_version');
exporter.addRelatedList('wf_condition', 'activity.workflow_version');
exporter.addRelatedList('wf_transition', 'to.workflow_version');
exporter.addRelatedList('wf_transition', 'from.workflow_version');
exporter.addRelatedList('wf_workflow_instance', 'workflow_version');
if(wfID != ''){
exporter.addQuerySet('wf_workflow', 'sys_id=' + wfID);
}
if(actID != ''){
exporter.addQuerySet('sys_variable_value', 'document_keyIN' + actID);
}
exporter.exportRecords(g_response);

Once you have your processor set up, you just need to call it. The processor above is called by its path name ‘export_workflow’ followed by ‘.do’. It also needs to know what to export so you need to pass it the sys_id of the top-level record that you want to export…in this case, the sys_id of the ‘Workflow context’ record.

‘Export to XML’ UI Action
Name: Export to XML
Table: Workflow Version (wf_workflow_version)
Order: 200
Form context menu: True
Hint: Export workflow for importing in another instance
Condition: gs.hasRole(“admin”)
Script:

action.setRedirectURL('export_workflow.do?sysparm_sys_id=' + current.sys_id + '&sysparm_wf_id=' + current.workflow);

Once you’re done with this, you should have an ‘Export to XML’ UI action context menu item on your ‘Workflow version’ form that you can use to transport workflows in the event that they don’t get captured in an update set.