DeactivateFlowDef API¶

Sets a workflow definition back to inactive state so its steps and tasks can be modified. A workflow must be inactive before steps or tasks can be added, removed, or changed.

This is the counterpart to ActivateFlowDef. The operation is idempotent: calling it on an already-inactive workflow returns success immediately without error.

Endpoint¶

/srv.asmx/DeactivateFlowDef

Methods¶

• GET /srv.asmx/DeactivateFlowDef?authenticationTicket=...&domainName=...&flowName=...
• POST /srv.asmx/DeactivateFlowDef (form data)
• SOAP Action: http://tempuri.org/DeactivateFlowDef

Parameters¶

Response¶

Success Response¶

<response success="true" error="" errorCode="0" />

Error Response¶

<response success="false" error="Session expired or invalid ticket" errorCode="4010" />

Required Permissions¶

The calling user must be a domain/library manager or a system administrator.

Example¶

GET Request¶

GET /srv.asmx/DeactivateFlowDef
    ?authenticationTicket=3f7a1b2c-4d5e-6f7a-8b9c-0d1e2f3a4b5c
    &domainName=Corporate
    &flowName=ContractApproval
HTTP/1.1
Host: yourserver

POST Request¶

POST /srv.asmx/DeactivateFlowDef HTTP/1.1
Host: yourserver
Content-Type: application/x-www-form-urlencoded

authenticationTicket=3f7a1b2c-4d5e-6f7a-8b9c-0d1e2f3a4b5c&domainName=Corporate&flowName=ContractApproval

JavaScript¶

Every call answers XML with HTTP 200, success or not, so success is the thing to branch on and errorCode is the number to report.

async function call(action, params) {
  const response = await fetch(`/srv.asmx/${action}?${new URLSearchParams(params)}`);
  const root = new DOMParser()
    .parseFromString(await response.text(), 'text/xml')
    .documentElement;

  if (root.getAttribute('success') !== 'true') {
    throw new Error(`${root.getAttribute('errorCode')}: ${root.getAttribute('error')}`);
  }
  return root;
}

Turns a definition off. Documents already in it keep running; new ones cannot be submitted. Calling it on a definition that is already off is accepted, so it is safe to run before every edit.

await call('DeactivateFlowDef', {
  authenticationTicket: ticket,
  domainName: 'Public',
  flowName: 'Invoice approval'
});

Notes¶

• The operation is idempotent: if the workflow is already inactive, the call succeeds without error.
• Unlike ActivateFlowDef, deactivation does not perform structural validation -" it always succeeds as long as permissions are met.
• After deactivating, you can add or remove steps and task definitions. When finished, call ActivateFlowDef to put the workflow back into service.
• Active workflow instances (documents currently in the workflow) are not affected by deactivation. Only new submissions are blocked while the definition is inactive.
• The typical edit cycle is: DeactivateFlowDef -' AddFlowStepDef / AddFlowTaskDef / DeleteFlowStepDef / DeleteFlowTaskDef -' ActivateFlowDef.

Related APIs¶

• ActivateFlowDef -" Activate the workflow definition so documents can be submitted to it.
• CreateFlowDef -" Create a new workflow definition (created in inactive state).
• AddFlowStepDef -" Add a step to an inactive workflow definition.
• AddFlowTaskDef -" Add a task definition to a workflow step.
• DeleteFlowStepDef -" Remove a step from an inactive workflow definition.
• DeleteFlowTaskDef -" Remove a task definition from a workflow step.
• GetFlowDef -" Retrieve the current state and definition of a workflow.
• DeleteWorkflow -" Permanently delete a workflow definition.

Error Codes¶

The errorCode values this operation returns, checked against a running server: