How to handle variable naming inconsistencies in IFS BPA Workflows

IFS BPA Workflows are a powerful way to automate business processes in IFS Cloud. They allow teams to automate approvals, check for validations, create integrations, and manage exception handling without hard-coding logic directly into the application. BPA workflows are an excellent choice for modern automation without the need for additional tools.

However, one practical challenge that often appears in real-world implementations is inconsistent variable naming when different processes execute the workflow.

The variable naming challenge in IFS BPA Workflows

Depending on how a BPA workflow is triggered (event action, projection call, REST integration, custom logic, etc.), IFS may pass process variables in different formats to your workflow. For example:

• PART_NO or PartNo

• QUANTITY or Quantity

These variables may represent the same business data, but from a workflow perspective they are different variables. 

If an event, and a projection both need to call the same workflow, it is likely that each will give you the data in different formats. Events will typically give you the database format (PART_NO) and projections typically give you PascalCase format (PartNo), however, this is not always the case and IFS is seemingly updating areas of the system so that events will send in PascalCase.

This naming problem can lead to:

• Additional scripting in every workflow

• Hard-to-read workflow models

• Bugs caused by missing or misnamed variables

• Extra maintenance when integrations change

• Separate instances of the same workflow, one to work with events and the other for projections. Double the workload of keeping them aligned.

The solution: Standardise variables once the beginning

The cleanest and safest approach is to standardise all incoming variables at the very start of the workflow, converting them into a single, consistent naming convention to make the workflow designing process easier and cleaner.

By doing this:

• The workflow only needs to work with one variable format

• All downstream tasks become simpler

• Integrations can send data in any supported format

• The process becomes easier to maintain and debug.

Techris Consulting Limited has created a script to convert all of the workflow variables into the PascalCase format. This will handle:

• Database-style names (PART_NO) > PartNo

• Uppercase names (QUANTITY) > Quantity

• Lowercase names (project) > Project

Any converted variables will still remain in the script. Although the original variables can be deleted, it is safter to validate the old and new variables and their values.

Where this script should be placed

You could use a Script Step in the workflow, however we prefer adding the script to the Start Event, as it means your workflow is focused on the process you are designing and not managing variables.

Why the Start Event?

• It runs once per process instance

• It executes before any tasks or gateways

• It guarantees that all subsequent workflow logic sees the standardised variables

• It avoids duplicating logic in multiple script tasks

This is the ideal place for:

• Variable standardisation

• Default value handling and initialisation of additional variables

• Input validation

• Process-wide setup logic

Step-by-Step: How to add the script

1. Open your workflow

2. Click on the Start Event of the workflow, this is the white circle with the thin border.

3. In the Properties Panel, open Listeners.

4. Add a new Execution Listener.

5. Configure it as follows:

   • Event Type: start

   • Listener Type: Script

   • Script Format: JavaScript

6. Paste the variable normalization script into the script editor.

7. Save and deploy the workflow.

Once deployed, the workflow will automatically standardise variables every time it starts.

You can test the script by entering variables in different formats on the Inspect window.

When you inspect the results of the test, you will see that the ones that are not already in PascalCase have been re-created in the correct format. The original variables remain in place.

Best practice recommendation

• Standardise variables once, at the start

• Be mindful that task steps may bring back new variables in a different case and you may need to re-standardise the new variables.

• Do not remove original variables unless you have a strong reason

This approach keeps BPA workflows robust and reliable, without the need to change each variable in a script. When your environment is updated with the latest patches, IFS may change the case of the variables that trigger your workflow. Using this method, they are more likely to continue working as designed.

The script

/**
 * Converts a database-style or lowercase variable name to PascalCase.
 *
 * Examples:
 *   PART_NO        -> PartNo
 *   TRANSACTION_ID -> TransactionId
 *   quantity       -> Quantity
 */
function toPascalCase(name) {
  return name
    .toLowerCase()
    .split("_")
    .map(function (part) {
      return part.charAt(0).toUpperCase() + part.slice(1);
    })
    .join("");
}

/**
 * Determines whether a variable name is already PascalCase.
 *
 * We treat PascalCase as the canonical naming convention
 * used throughout the process after normalization.
 */
function isPascalCase(name) {
  return /^[A-Z][a-zA-Z0-9]*$/.test(name);
}

/**
 * Main logic.
 *
 * This runs once when the process instance starts.
 * It scans all incoming process variables and ensures
 * that a PascalCase version exists for each value.
 *
 * IMPORTANT:
 * - Original variables are NOT removed
 * - Existing PascalCase variables are never overwritten
 */

var vars = execution.getVariables();

for (var key in vars) {

  // Skip variables that are already in correct PascalCase
  // and do not use underscores
  if (isPascalCase(key) && key.indexOf("_") === -1) {
    continue;
  }

  var pascalKey;

  if (key.indexOf("_") !== -1) {
    // Database-style variable name (e.g. PART_NO)
    pascalKey = toPascalCase(key);
  } else {
    // Uppercase or lowercase single-word variable (e.g. QUANTITY, quantity)
    pascalKey =
      key.charAt(0).toUpperCase() +
      key.slice(1).toLowerCase();
  }

  // Never overwrite an existing canonical variable
  if (execution.hasVariable(pascalKey)) {
    continue;
  }

  // Create the PascalCase variable for use throughout the process
  execution.setVariable(pascalKey, vars[key]);
}

Remove Variables

Although we do not recommend removing the variables, this additional block of code would allow you to remove any variables using the DATABASE_FORMAT case. This should always exist outside of the main process to avoid any issues. We have seen some slowness with this area, so please be extra cautious if you use this section.

/**
 * Remove logic.
 * This should be added with extreme caution. This will remove 
 * variables with underscores. If used, it should be at the 
 * END of the script.
 */

var toRemove = [];

for (var key in vars) {
  if (key.indexOf("_") !== -1) {
 // Database-style variable name (e.g. PART_NO)
    toRemove.push(key);
  }
}

for (var i = 0; i < toRemove.length; i++) {
  execution.removeVariable(toRemove[i]);
}

Disclaimer

The information and example scripts provided in this article are supplied for general guidance purposes only. While Techris Consulting has taken reasonable care to ensure the accuracy and reliability of the approach described, all scripts and configuration examples are provided “as is”, without warranty of any kind.

Implementation and use of the script is the responsibility of the customer. Techris Consulting accepts no liability for any loss, damage, system instability, or unintended behaviour arising from the use, modification, or deployment of this script within an IFS BPA workflow or any related system.

Customers are strongly advised to review, test, and validate the script in a non-production environment prior to deployment, and to ensure it aligns with their internal development, security, and governance standards.