Best practice for handling wkfs during server downtime | Community
Skip to main content
A
A_B_SE
Level 4
September 24, 2025
Solved

Best practice for handling wkfs during server downtime

  • September 24, 2025
  • 2 replies
  • 691 views

We are preparing for a server upgrade, during which the OS server will be down for a couple of business days. We currently have thousands of active workflows running continuously, and we want to avoid the need to stop and restart them manually.

Due to specific filters in our database tables, administrators cannot restart all workflows on their own. Instead, we would need to rely on specific users to restart workflows manually, which is both time-consuming and operationally complex.

My question is:

  • Is there a best practice or an automated way to handle workflows during the downtime?
  • For example, is there a way to pause all workflows at once and then resume them after the upgrade?
  • Alternatively, are there any recommendations for minimizing the impact of the downtime on workflows and avoiding manual intervention? Maybe altering some settings in ACC like typology rules etc.

We would greatly appreciate your insights and recommendations on how to handle this situation efficiently.

Thank you in advance for your help!

Best answer by DavidKangni

@a_b_se 

 

Run the nms:freezeInstance.js cauterization script on the target environment before starting it up.

To do this, run the following command:

nlserver javascript nms:freezeInstance.js -instance:<dev> -arg:run

This process does not impact the servers and their configuration. In the context of Adobe Campaign, a cauterization combines actions that let you stop all processes interacting with the outside: logs, tracking, deliveries, campaign workflows, etc.

 

Once you restart your server, it will automatically resume all processes

 

Thanks,

David

2 replies

SushantTrimukheD
SushantTrimukheD
Level 4
September 25, 2025

Hi @a_b_se,

I suggest using a workflow to query the workflow schema in order to retrieve the workflow names, internal names, or primary keys (PK) of the workflows that are currently in the "start" status. Save this list somewhere, or export it to a CSV file.

Once your server is back online, you can use this CSV to identify the internal names or PKs of the workflows that were in the start stage before the upgrade. With that information, you can run the code below to restart those workflows.

This approach can be further improved by directly reading the temporary CSV data in JavaScript and iterating through it in a loop to start the workflows, using the provided code as a foundation.

// List of workflow internal names to start var workflowList = ["wkfInternalName1", "wkfInternalName2", "wkfInternalName3"]; // replace with your internal names for (var i = 0; i < workflowList.length; i++) { try { xtk.workflow.Start(workflowList[i]); logInfo("Started workflow: " + workflowList[i]); } catch(e) { logError("Error starting workflow: " + workflowList[i] + ". Error: " + e); } }

 
Thanks
Sushant Trimukhe

A
A_B_SEAuthor
Level 4
September 25, 2025

Hello @sushanttrimukhed ,
Is it possible to make those wkfs restart by different operators by coding it somehow in the JS?

example:
wkf1 started by operator1

wkf2 started by operator2

As I mentioned we have special rules and filters in different tables that can cause problems at filtering level. We do not want to risk to send emails and smses to customers that we are not allowed to target.

SushantTrimukheD
SushantTrimukheD
Level 4
September 25, 2025

Hi @a_b_se,
 

By default, workflows started via JavaScript API methods such as xtk.workflow.Start() run under the operator executing the script. Currently, there is no built-in JavaScript or API feature that allows you to start or impersonate a workflow as a different operator dynamically within the script.

I’m not sure how many operators and workflows you have. If the number of operators is small, and each operator knows which workflows they are responsible for, one option is to have each operator export their list of workflows to a CSV file and then restart those workflows themselves using the script. In other words, each operator manages the restart of their own workflows.

I understand this is a manual approach. However, if you are an admin and already know which workflows were in the running state before the server upgrade—and need to be restarted afterward—then this should not be a problem in practice.

Thanks
Sushant Trimukhe

DavidKangni
Community Advisor
DavidKangniCommunity AdvisorAccepted solution
Community Advisor
September 25, 2025

@a_b_se 

 

Run the nms:freezeInstance.js cauterization script on the target environment before starting it up.

To do this, run the following command:

nlserver javascript nms:freezeInstance.js -instance:<dev> -arg:run

This process does not impact the servers and their configuration. In the context of Adobe Campaign, a cauterization combines actions that let you stop all processes interacting with the outside: logs, tracking, deliveries, campaign workflows, etc.

 

Once you restart your server, it will automatically resume all processes

 

Thanks,

David

David Kangni
Terms & ConditionsAccessibility statement

Loading footer...