Operations

Backup

Overview

The data and database files should be backed up regularly to preserve the reliability of the processes and their associated data.

• It's strongly recommended to perform the file and database backup at the same time. To enforce data integrity, it's also recommended to stop IIS and database services.

• The following procedures apply to MS SQL Server only.

Full (applications and data)

Application and data files

Back up the DRIVE:\Inetpub\wwwroot\wfgen folder.

If you've applied file storage, back up the folder as indicated in the ApplicationDataPath parameter in the web.config file.

Database

Perform a standard SQL database backup using your DBMS tools.

Data only

Database

Perform a standard SQL database backup using your DBMS tools.

Data files

Back up the DRIVE:\Inetpub\wwwroot\wfgen\App_Data folder.

Moving the WorkflowGen database

SQL Server database

To move the WorkflowGen SQL Server database from one server to another:

1. Stop IIS services on the production server.

2. Detach the WorkflowGen database.

3. Copy the .mdf and .ldf files to the new location.

4. Attach the file to the new database server.

5. Update the connection string in the Administration Module Configuration Panel.

6. Restart your IIS services.

Moving the WorkflowGen application

To move the WorkflowGen installation from one server to another:

1. Stop IIS services on the production server.

2. Set up the same version of WorkflowGen on the new server.

3. Copy the DRIVE:\Inetpub\wwwroot\wfgen\App_Data folder from the old server to the new one if you haven’t applied file storage externalization.

4. If you've created your own web forms, SDK applications, or web services:

   1. Copy their folders in the corresponding tree structure of the new server. For example, if you've created a web service named MyWebService located in DRIVE:\wfgen\wfapps\WebServices\MyWebServices then you need to copy the entire folder to the same place on the new server.

   2. Create the IIS application with the same directory security options on the new server for the applications you've copied.

   3. For web services or SDK Applications, make sure to update the application URL in the Administration Module.

   4. For web forms, be sure to update the FORM_URL data in the process definition to point to the new URL.

   5. Repeat this process for every custom application you've created.

5. Update the application URL from the Administration Module Configuration Panel.

Monitoring

Storage space

File data

The only folder that you need to monitor for storage space is DRIVE:\Inetpub\wwwroot\wfgen\App_Data. The other folders should always keep the same size because everything that is generated over the time is placed in this directory.

Database

The database size can be determined by checking the .mdf and .ldf files if you're using SQL Server, or using your DBMS tools.

Storage space needs may vary depending on whether or not the Store file content in database process data storage option is selected during the process definition.

Directory synchronization

The directory synchronization log files can be found in the \wfgen\App_Data\LogFiles\Dir\Synchro directory. Alternately, you can consult and manage the logs history directly in the WorkflowGen Administration Module.

Windows Services

Windows Services should be set to run automatically when the server starts. Periodically, Windows Services will perform the following necessary tasks:

• Raise overdue exceptions

• Send overdue notifications

• Delete inactive delegations

• Delete ghost activities (activities initialized but never started)

Usage

Requests/actions by day

A statistics module and charting functions are provided in the User Portal to generate detailed reports on the requests and actions. You can customize reports using filters.

Attachment file size

Attachments to requests submitted using web forms are saved in the DRIVE:\Inetpub\wwwroot\wfgen\App_Data\Files\EFormASPX temporary folder and are automatically deleted 24 hours after their creation.

WorkflowGen will copy those runtime files to a permanent location. If the Store file content in database process data storage option is enabled, then they are stored directly in the database. Otherwise, they're stored in the file system as determined by the ApplicationDataPath configuration parameter (e.g. \App_Data\Files\DataSet\runtime).

If you know that a process takes too much space on the disk because of the process data, or too much space in the database because of file attachments, you can turn off the Archive action associated data option in the process definition. This will prevent the attached file from being stored for each action of every request. Only the data after the last action will be kept on the disk or in the database.

MCP OAuth maintenance

When the WorkflowGen MCP Server is enabled, OAuth client registrations, authorization transactions, authorization codes, refresh tokens, and signing keys are stored in the in the WorkflowGen database OAUTH_* tables.

Keep OAuthServerKeyEncryptionKey stable after MCP has been enabled. If the key is changed after an active signing key exists, the MCP Server may no longer be able to decrypt the stored private signing key and token issuance can fail.

If a full MCP OAuth reset is required, plan it as a support-assisted maintenance operation. Resetting OAuth client registrations, tokens, and signing keys can force MCP clients to reconnect.

Change events operations

Key custody and backup

The integrity key is required for event append, integrity verification, and authenticated retention. Store it in the deployment's approved secret manager and keep a recoverable protected copy separate from ordinary database access. A database backup without the original key does not provide a verifiable or continuable Change events chain.

• Never paste the key into a ticket, log, screenshot, runbook example, or documentation repository.

• Do not generate a replacement key after the first protected event.

• There is currently no supported rotation or reset procedure.

Verifying Change events activation

After configuring the key and restarting or rolling out every applicable web and engine service instance, do the following:

1. Confirm that the intended enabled mode is active: Standard for a first activation, or the preserved Standard or Full mode after an upgrade.

2. Create and rename a disposable test category.

3. Open Change events in the Administration Module and confirm that the corresponding events appear with the expected user, item, and previous/new values.

4. Delete the test category and confirm that its deletion event appears.

5. Click Integrity then Verify integrity in the Integrity status panel, and confirm that the result is Valid.

If any step fails, reset the mode to Off and follow the guidance in Recovery below before attempting activation again. Do not lower production retention to test deletion.

Verifying integrity

You should perform an explicit verification after initial activation, after restoring a database or key, after a version upgrade, and whenever integrity readiness or stored-report status is unhealthy or stale. A Valid result authenticates the retained protected chain through the verification snapshot. New events after that snapshot make the report stale and require another verification when current evidence is needed.

Recovery

Situation	Response
Standard or Full activation is rejected	Leave mode set to Off. Verify the key format, database migration, provider, runtime permissions, and integrity state. Do not force activation by editing internal database rows.
One node has the wrong or missing key	Restore the exact original key on every applicable node, recycle or restart, and run integrity verification. Do not create a replacement key.
Normal Administration Module access is blocked	If necessary, set mode to Off in the Configuration panel. This restores other pages but hides Change events and does not repair the chain.
Key is lost or unavailable	Set the mode to Off, preserve the database, and restore the exact key from the protected backup. After all nodes are corrected, pause traffic, enable the intended mode, and immediately verify integrity. If no trusted backup exists, contact Support.
Key is suspected compromised or disclosed	Set the mode to Off, preserve the database and evidence, contain access to the database and secret, and contact Support. The current version has no supported rotation or reset; continuing with the disclosed key does not remediate compromise.
Integrity verification fails	Preserve a database copy first. Use available diagnostic history only as unverified evidence. Do not edit event hashes, head rows, checkpoints, or event rows manually.
Migration or permissions failed	Stop application traffic, correct the normal grants or safely rerun the provided script, then retry while the mode remains set to Off.
Retention already removed records	Only an external database backup can recover deleted payloads. The checkpoint cannot reconstruct them.

📌 Example of a key recovery

If one node starts with a missing or different key, set the capture mode to Off, restore the exact original key on that node and every other applicable instance, recycle or restart the deployment, restore the intended mode while traffic is quiesced, and run an integrity verification. Generating a replacement key does not recover the existing chain.