Hi Manasa2K12,

For applications in production changes to flow rules already in use should be undertaken with caution. Note that the flow rule holds the state of the work item so changes may invalidate assignments on existing work items.  Also the addition of local actions allows users to perform these new local actions on existing assignments which were created prior to the changes to the  flow rule (this may be advantages and desirable).

Some changes to flows may cause problems, for example: Removing an assignment shape for which there are open assignments will result in orphaned assignments.  Replacing an assignment shape by a new one with the same name may result in a problem since flow processing relies on an internal name for each shape.  Removing or replacing wait points (such as Subflow and Split-for-each shapes) in the flow, may cause problems since their shape IDs are referenced in active subflows.

The following 4 Solutions outline different techniques to handle changes to flows in production. Note that there is no one technique which is best since each option has its pros and cons. The solution you implement might involve a combination of these techniques.  Also consider testing the changes again in a staging environment using a subset of live "in flight" cases from production and then again once they have been migrated to the production environment.

Solution 1:

Create a new flow rule using Circumstancing and leave the base flow as it is. For circumstancing set pxCreateDateTime property to the date the change will go into production.  Update the flow and save it to the new RuleSet version.  The new flow rule will only be executed for new work objects (a.k.a. work items or cases) when the changes go into production.  Also, clear the Create a new work object check box on the old flow rule.  This ensures that the New Work (Case) gadget shows only the new flow rule.

Pros and Cons of Solution 1:

Advantage - easy to implement if flows aren’t too deeply nested.

Disadvantage - number of flow rules grow and may be hard to maintain.

Not recommended if the changes require modification of subflows four or more levels deep.

Solution 2:

Leave all the old flow wait points unchanged and implement the changes in parallel in the same flow.  Leave the shapes to be deleted or changed as they are keeping the outgoing connectors intact.  This way existing assignments follow the same old path.  A report can be run to see if there are any old assignment instances. If there aren’t any, the flow wait points can be removed in the next version of the flow. Implement the changes making sure that new work objects never reach the outdated shapes. Save the flow you want to update to the new RuleSet version.

Pros and Cons of Solution 2:

Advantage - allows all work objects to use the same rule names across multiple versions.

Disadvantage - might not be feasible depending on the changes and produces cluttered flow diagrams (which in turn violates a Pega Best Practice: Keep the number of shapes in any flow rule to 15 or less).

Solution 3:

Add tickets in the newly modified flows to control where the processing of each type of old assignment is to resume processing.  Then run a bulk processing job that finds all the outdated assignments and for each assignment call the Assign-.OpenAndLockWork and then Work-.SetTicket on the work page.

Pros and Cons of Solution 3:

Advantage - leaves the flow rules clean.

Disadvantage - might be impractical if the number of assignments is large, or if there is no moment when the background processing is guaranteed to acquire the necessary locks when running the required bulk processing job.

Solution 4:

Revert the user’s RuleSet list to the original, lower versions when dealing with the older assignments. Also create an extra access group that points to the older version of the application.  Adding the access group to the operators enables them to use the Switch Apps functionality to switch to the older version of the application. In effect you will be running both the old and the new versions of the application simultaneously until all the live "in-flight" cases are resolved.

Pros and Cons of Solution 4:

Advantage - only sure approach that supports changes beyond just the flow rules.

Disadvantage - fixes in higher RuleSet versions aren’t included because the user’s RuleSet list is using older versions that do not include them.

How to Handle Flow Errors:

Flow errors can be found on the Flow Error landing page: DesignerStudio > Process & Rules > Processes > Flow Errors. If flow errors occur, utilize the features on this page to fix them, they include:

Resume Flow - resume flow execution beginning at the step after the step that paused.

Retry Last Step - resume flow execution, but begin by re-executing the step that paused.

Restart Flow - start the flow at the initial step.

Delete Orphan Assignments - delete assignments for which the work item cannot be found.

Hope this helps,

Henry

Pega Academy