Script to create reporting settings on user created Flows, Subflows, and Actions

Wayne Richmond
Tera Guru

3 weeks ago

I was annoyed to find that reporting had been disabled on my Flows and Actions after upgrading to Australia. I was told to update each one individually when required, which seems akin to closing the gate after the horse has bolted. So, I've created a script to set reporting on all user-created Flows, Subflows, and Actions. Use this at your own risk. Read this article to understand the potential impact: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB3024064

 

if you have any concerns, comments, suggestions, please respond below. Thanks

 

// This script creates reporting settings for Flow, Subflows, and Actions
// Toggle the updateFlows and updateActions variables depending on what you'd like to update
// Set a reporting level
// Set logging if required
// This script will not update records created by admin, maint, or anyone at ServiceNow, as per the flowActionGr.addEncodedQuery('sys_created_byNOT LIKE@snc'); encoded query
// Uncomment flowActionGr.setLimit(3); for testing a small number of records

(function() {

    var updateFlows = true; // true | false
    var updateActions = true; // true | false
    var reporting = 'FULL'; // BASIC | FULL | TRACE | OFF
    var logging = ''; // WARN | ERROR | INFO | DEBUG

    // Validate variables
    if (reporting == '') {
        gs.info('Set a reporting level');
        return;
    } else if (reporting != 'BASIC' && reporting != 'FULL' && reporting != 'TRACE' && reporting != 'OFF') {
        gs.info('Set a valid option for reporting (BASIC, FULL, TRACE, or OFF)');
        return;
    }
    if (logging != '' && logging != 'WARN' && logging != 'ERROR' && logging != 'INFO' && logging != 'DEBUG') {
        gs.info('Set a valid option for logging (WARN, ERROR, INFO, or DEBUG)');
        return;
    }

    if (updateFlows == true) {
        createReportSettings('sys_hub_flow', 'flow');
    }
    if (updateActions == true) {
        createReportSettings('sys_hub_action_type_definition', 'action');
    }

    function createReportSettings(table, flowType) {
        var flowActionGr = new GlideRecord(table);
        // flowActionGr.setLimit(3); // Limit for testing
        flowActionGr.addActiveQuery();
        flowActionGr.addQuery('sys_created_by', '!=', 'admin').addCondition('sys_created_by', '!=', 'maint');
        flowActionGr.addEncodedQuery('sys_created_byNOT LIKE@snc');
        flowActionGr.query();
        while (flowActionGr.next()) {
            var newReportSettingsGr = new GlideRecord('sys_flow_execution_setting');
            if (newReportSettingsGr.get('source', flowActionGr.sys_id)) {
                gs.info('Reporting is already set to ' + newReportSettingsGr.reporting + ' for "' + newReportSettingsGr.source.name + '" ' + flowType);
            } else {
                newReportSettingsGr.initialize();
                newReportSettingsGr.setValue('source_type', table);
                newReportSettingsGr.setValue('source', flowActionGr.sys_id);
                newReportSettingsGr.setValue('reporting', reporting);
                newReportSettingsGr.setValue('logging', logging);
                newReportSettingsGr.insert();
                gs.info('"' + newReportSettingsGr.source.name + '" ' + flowType + ' reporting set to ' + reporting);
            }
        }
    }

})();

 

0 Helpfuls
  • 370 Views
1 REPLY 1

Vikram Reddy
Tera Guru

3 weeks ago

Hey @Wayne Richmond,

 

You're not imagining this one. Flow reporting has been off by default since Rome, and Australia Patch 2 added its own wrinkle where the com.snc.process_flow.reporting.level property falls back to BASIC on production instances (that's KB3024064). Backfilling sys_flow_execution_setting directly is exactly the right move too, that's the same table Flow Administration > Settings reads and writes when you toggle reporting from the UI, so your script and the native admin screen are doing the identical database operation.

newReportSettingsGr.initialize();
newReportSettingsGr.setValue('source_type', table);
newReportSettingsGr.setValue('source', flowActionGr.sys_id);
newReportSettingsGr.setValue('reporting', reporting);
newReportSettingsGr.setValue('logging', logging);
newReportSettingsGr.setWorkflow(false); // skip BRs/audit on bulk insert
newReportSettingsGr.insert();

The one addition I'd make is setWorkflow(false) before the insert. It skips business rules and audit history on that GlideRecord write, which matters once you're inserting hundreds of these in one transaction against sys_flow_execution_setting.

A couple of things worth doing before you run it org-wide:

  • Export the current sys_flow_execution_setting table (or capture it in an update set) so you have something to roll back to
  • Run it in a sub-prod instance first with your setLimit(3) line uncommented
  • Also check the com.snc.process_flow.reporting.level system property, since it controls the default for any flow created after this script runs, your script only backfills what already exists

References

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls