Avoid Rebase and Naming Conflicts for Workflow Processes

Previous to the Workspace Enablement of Workflow Processes and Tasks, only one version of a Workflow Process could be "Completed" (or active) at a given time. When a change was required to a Workflow Process, the developer would create a new version – which would become "In Progress" and eventually would replace the older version once it was fully tested. At that point, the older version would become "Obsolete" and the "In Progress" version would switch to "Completed" – representing that it is the current version.

In a Siebel Database Upgrade or Incremental Repository Merge (IRM) scenario, coming from a pre-2017 version of Siebel CRM, it is possible that some Workflow Processes have Obsolete, In Progress, and Completed versions, with the In Progress versions representing work that is not yet complete. During the (IRM/Database Upgrade) repository merge process, the logic assumes that the latest completed version should become the active version in the new Workspace model, which would ultimately end up in MAIN\0 in the upgraded Siebel Repository. Because only one version of an object is allowed in a given Workspace/Version combination, the other versions are renamed to include their version number, allowing them to be kept moving forward.

For example, consider an "ABCD Workflow Process" that has three obsolete versions, one completed version, and two in-progress versions in the pre-Siebel CRM 2017 database. The following table shows what will happen to the names of these Workflow Processes during the IRM/Upgrade merge process.

Old Workflow Process Name	Old Workflow Process Version	Old Workflow Process Status	New Workflow Process Name After Upgrade	Inactive Flag
ABCD	1	Obsolete	ABCD: 1	Y
ABCD	2	Obsolete	ABCD: 2	Y
ABCD	3	Obsolete	ABCD: 3	Y
ABCD	4	Completed	ABCD	N
ABCD	5	In Progress	ABCD: 5	Y
ABCD	6	In Progress	ABCD: 6	Y

As shown in this table, the merge is able to keep all versions of the Workflow Process, regardless of status, and only the one that was active in the previous environment (with status of "Completed") remains active in the upgraded repository.

Note: If there are multiple completed versions, then the latest completed version will be active.

Now consider a situation where the developer wants to resume work on version 6 of the Workflow Process having previously worked on version 6 in the old database before the upgrade put a hold on that work. The logical path to do this would be to create a workspace, remove the inactive flag, make the required changes, test, and deliver the Workflow Process. The goal, however, is to deliver the Workflow Process as "ABCD" (since it is intended to replace the existing version). The developer cannot simply rename the Workflow Process because there is already a Workflow Process with that name.

To address this issue, the developer should do the following:

1. In the DEV Workspace before attempting to rebase, rename the old version to "ABCD-OLD" (for example) and mark it as Inactive.

2. Rename the new, replacement workflow to "ABCD" (in this example).

Doing this ensures everything will be successfully delivered, and subsequently migrated, upon rebase or delivery.