Important Notes Before Upgrading

Update .NET version

WorkflowGen 10.4.0 requires .NET Framework 4.8, so you must install it before proceeding with this upgrade.

Update the root web.config file's URL rewrite rules

As of WorkflowGen 9.2.0, you MUST update your site's root web.config file with the new URL rewrite rules, based on how your WorkflowGen URL is configured. For instructions on how to do this, see the Update the root web configuration file section.

Using BACKURL_SUBMIT and BACKURL_CANCEL parameters in custom WorkflowGen URLs

As of version 7.15.5, the optional BACKURL_SUBMIT and BACKURL_CANCEL HTTP parameters used in custom WorkflowGen URLs (for example, when launching a new request and starting the first action within another website) now ONLY support absolute URLs (starting with http:// or https://), relative URLs (starting with /), or URLs defined in the PortalRedirectAllowedHttpUrls configuration parameter (e.g. value='blank.htm, myPage.htm').

Password encryption change

As of version 7.15.0, the SMTP server account and Remote Approval incoming server account passwords are no longer encrypted in the web.config file.

Before upgrading an existing WorkflowGen server, you must manually reset the passwords in cleartext for the ApplicationSmtpPassword and RemoteApprovalIncomingServerPassword parameters in the web.config. Alternatively, you can use the provided convert-web-config-pwd.ps1 PowerShell script in \wfgen to decrypt and convert the passwords in the web.config.

Database server

Microsoft SQL Server 2025, Azure SQL Database with the Integrated Vectorization feature, or PostgreSQL 17.6 is required for WorkflowGen v10.

Migrating a legacy WorkflowGen database from MS SQL Server 2005/2008

This database compatibility upgrade is mandatory before migrating the WorkflowGen database from MS SQL Server 2005/2008.

It's not required if your WorkflowGen database is already running in MS SQL Server 2012 or later.

To do this, launch the Update\Databases\MsSQLServer\Update_WFG-V7-0_SQL_Triggers_2012.sql database update script in your SQL Server Management Studio tool.

Node.js modules

The Node.js modules include the GraphQL API, webhooks, SCIM, Auth, and MCP Server. For instructions on how to enable them, see the WorkflowGen Node.js-based web applications section.

Upgrade Node.js version

Upgrade Node.js to version 24.19.0 LTS (see https://nodejs.org/download/release/v24.19.0).

WorkflowGen MCP Server also adds OAuth persistence tables to the WorkflowGen database. Make sure the WorkflowGen database update script has been applied before enabling MCP.

GraphQL and incoming webhooks file upload management parameters

As of WorkflowGen version 7.10.0, if you're using incoming webhooks or GraphQL to upload files when starting a new request or completing an action, you must set the GraphqlFileInputAllowedFolders, HooksFileInputAllowedFolders, GraphqlMaxInputFileContentSize, and HooksMaxInputFileContentSize configuration parameters with the appropriate values (see the When upgrading from version 7.9.1 and earlier section).

• GraphqlFileInputAllowedFolders and HooksFileInputAllowedFolders: These parameters should contain the physical paths of folders that contain files used in uploads.

• GraphqlMaxInputFileContentSize and HooksMaxInputFileContentSize: These parameters should contain the maximum file size in kilobytes when uploading files using the file content method.

  ✏️ Note: We recommend limiting the file content size to small files under 1 megabyte.

GraphQL and incoming webhooks XPDL file access restrictions

As of WorkflowGen version 10.4.0, GraphQL and incoming webhook operations that use xpdl.url to access server-local XPDL files are restricted to trusted folders.

Before upgrading, review any existing integrations that pass a server-local file:// URI using xpdl.url. If an XPDL file is located outside the application's managed upload directory, add its trusted directory to the corresponding configuration parameter:

• GraphqlInputFileAllowedFolders: Comma-separated list of trusted folders for GraphQL input file

• HooksInputFileAllowedFolders: Comma-separated list of trusted folders for incoming webhook input files.

Use narrowly scoped directories controlled by WorkflowGen administrators. The resolved file and its existing parent path must remain inside an allowed directory and must not traverse junctions, symbolic links, or other reparse points.

📌 Example

<add key="GraphqlInputFileAllowedFolders" value="D:\WorkflowGen\TrustedDefinitions" />
<add key="HooksInputFileAllowedFolders" value="D:\WorkflowGen\TrustedDefinitions" />

When these parameters are empty, WorkflowGen still allows files located in the corresponding managed upload directory under the configured ApplicationDataPath:

• GraphQL: Files\GraphQL\Uploads

• Incoming webhooks: Files\Hooks\Uploads

Existing multipart file uploads therefore continue to work without configuring an additional trusted folder. Existing integrations that use xpdl.url to read files from other server-local directories must add those directories to the appropriate configuration parameter before upgrading.

• Inline XPDL content must be Base64-encoded valid UTF-8 and must not exceed the configured input file size limit. Invalid UTF-8 content is rejected instead of being decoded using replacement characters.

• MCP artifact files are managed separately by the McpInputFileAllowedFolders configuration parameter and the MCP managed upload directory.

Configuring custom web forms in WorkflowGen 8 or later

If you're using custom web forms configured in .NET 2.0, you can keep using them in .NET 2.0 or migrate them to .NET 4.

To configure custom web forms for .NET 2.0

1. Use WorkflowGen.My.dll in version 2.x.

2. Use a .NET 2.0 application pool.

3. Disable Web apps secure mode in the Security section on the General tab in the Configuration Panel.

4. Define or update the following nodes in the web form’s web.config:

   <configuration>
       <system.web>
           <pages validateRequest="false" enableSessionState="true" />
       </system.web>
   </configuration>

5. If your web form’s authentication is configured to use the built-in WorkflowGen authentication mode, then the new password hashing mode (One-way Hashing) introduced in version 6.1 will not be compatible with your web form. There are two solutions:

   • Use Version 5 password management mode instead. Make sure to use the Advantys.My.dll and Advantys.Security.dll files from version 5.x in the web form’s \bin folder.

     OR

   • Migrate your web form to .NET 4. Make sure to use the Advantys.My.dll and Advantys.Security.dll files from WorkflowGen version 8.x in the in the web form’s \bin folder. For instructions on how to do this, see the next section.

To migrate custom web forms to .NET 4

1. Use WorkflowGen.My.dll in version 8.x.x or later.

2. Use a .NET 4 application pool.

3. Define or update the following nodes in the web form’s web.config:

   <configuration>
       <system.web>
           <httpRuntime requestValidationMode="2.0" targetFramework="4.8" />
           <pages validateRequest="false" enableSessionState="true" clientIDMode="AutoID" controlRenderingCompatibilityVersion="3.5" />
       </system.web>
   </configuration>

4. If your web form’s authentication mode is configured with the built-in WorkflowGen authentication, then make sure to use the Advantys.My.dll and Advantys.Security.dll files from version 8.x.x or later in the web form’s \bin folder.

• These instructions apply only to configuring web forms to run properly without configuration errors. They do not cover potential migration or compatibility issues that may arise due to changes in the latest version of WorkflowGen.My. You must fully retest all of your web forms before production.

• After an upgrade or migration to WorkflowGen 8 or later, custom web forms that use a version 8 or later WorkflowGen.My.dll in their custom \bin folders require the WorkflowGenMy.*.resx resource files in their App_GlobalResources sub-folders.

Preserving Change events configuration

This section does not apply when upgrading from a version earlier than 9.7.0, or if Change events was never enabled. In those cases, use the normal first-time activation procedure after completing the upgrade.

When upgrading from WorkflowGen version 9.7.0 or later, you must preserve the existing Change events integrity key and data if this feature was enabled. Do not replace the key with the empty sample value.

Under Change events on the Administration Module Configuration panel General tab, set the Audit mode to Off before the upgrade and retain the exact key on every web and engine service instance sharing the database. After every instance has been upgraded, restore the previous mode and follow the instructions in the Verify Change events activation in the Technical Guide Operations documentation.

Do not combine this product upgrade with a database-provider migration.

When deploying a custom assembly SDK workflow application

The WorkflowGen.My and Workflow Web Controls assemblies are no longer strong-named in order to allow non-specific version dependency when referenced by other applications such as custom assembly SDK Workflow applications in WorkflowGen.

This simplifies the deployment procedure of an assembly SDK Workflow application to WorkflowGen 6.2.0 and later, and allows upgrading WorkflowGen to a newer version without having to rebuild the application's assembly that was referencing an older version of WorkflowGen.My.

There are some considerations when deploying a custom assembly SDK workflow application in WorkflowGen, namely the assembly location, the reference to WorkflowGen.My, and the reference to other software libraries.

Assembly location

There are two ways of deploying an assembly file in WorkflowGen.

Method 1: Reference by assembly's full name

The assembly file must be copied to the three \bin folders containing the WorkflowGen executable files: \wfgen\bin, \wfgen\ws\bin, and DRIVE:\Program Files\Advantys\WorkflowGen\Services\bin.

Method 2: Reference by assembly's path (full physical path with file name)

The assembly file can be copied to a custom folder such as DRIVE:\MyWorkflowApps\Assembly.dll, and then use that specific path in the workflow application's definition.

Reference to WorkflowGen.My

WorkflowGen.My 3.1.0 and earlier

WorkflowGen.My versions 3.1.0 and earlier are strong-named, which means your assembly must be built with and use the same version as your target WorkflowGen. This requires recompiling your assembly whenever you upgrade WorkflowGen to a newer version.

You can use one of the following workarounds to overcome this requirement:

1. Install the required WorkflowGen.My version in the system's Global Assembly Cache (GAC). For instructions on how to do this, see https://msdn.microsoft.com/en-us/library/6axd4fx6(v=vs.110).aspx.

   OR

2. Add a delegate to handle the assembly resolve event in order to load the current WorkflowGen.My version. For instructions on how to do this, see the How to add an assembly resolve event delegate to overcome WorkflowGen.My dependency issue when deploying custom assembly SDK workflow application WorkflowGen Knowledge Base article.

   OR

3. Add a web configuration setting to redirect the required version to the current version of WorkflowGen.My. For more information, see https://msdn.microsoft.com/en-us/library/twy1dw1e(v=vs.110).aspx.

If your assembly is built with WorkflowGen.My version 3.1.0 or earlier, it can be used in WorkflowGen versions 6.2.0 and later if one of the above workarounds has been implemented.

WorkflowGen.My 3.2.0 and later

As of version 3.2.0, WorkflowGen.My is no longer strong-named in order to allow non-specific version dependency when referenced by your assembly. You can simply deploy your assembly file using one of the two methods in the Assembly location section above in WorkflowGen version 6.2.0 and later.

If your assembly is built with WorkflowGen.My version 3.2.0 or later, it can be used in WorkflowGen versions prior to 6.2.0 if you've implemented either workaround 2 or 3 above.

Reference to other software libraries

If your assembly uses third-party libraries, then these must also be deployed into the three WorkflowGen executable \bin folders. Alternatively, they can be installed into the system's Global Assembly Cache (GAC) if they are strong-named assemblies.

FIPS compliance configuration

WorkflowGen is FIPS compliant as of version 7.10.0. If you want to enable FIPS compliance in your Windows environment, you have to configure the configuration password management and user password management modes beforehand.

Configuration password management mode

In the Security section on the Configuration Panel General tab, set Configuration password management mode to AES (FIPS Compliant) and enter a 32-character encryption key. When you click Save, the application passwords will automatically be converted to the new symmetric encryption mode.

User password management mode

In the Authentication section on the Configuration Panel General tab, set Password management mode to One-way Hashing (SHA256 FIPS Compliant) mode.

• If you're using Applicative authentication in Version 5 (Legacy) password management mode, users' passwords will automatically be converted into One-way Hashing (SHA256 FIPS Compliant) the next time they log into WorkflowGen.

• If you're using Applicative authentication in One-way Hashing (SHA256) password management mode:

  1. Select IIS authentication mode.

  2. Select One-way Hashing (SHA256 FIPS Compliant) password management mode, then click Save.

  3. Re-enter all user passwords.

  4. Reset the authentication mode to Applicative.

Legacy software support

Browser and OS versions

WorkflowGen no longer supports Internet Explorer, Windows XP, Windows 7, Windows 8, or Windows Server 2003 or 2008.

Database

All MS SQL Server versions prior to 2025 or Azure SQL Database without the Integrated Vectorization feature are not supported.

Oracle database is not supported.

Workflow applications

The following applications are deprecated and are no longer provided as of WorkflowGen version 6:

• EFORMPDF

• DOCAPPROVAL

• DOCUPLOAD

• FDFTOXML

• PDFTODATABASE

However, if any of your processes still use these workflow applications, you can keep them declared under the WorkflowGen website as in version 5.