Changing Existing Processes

You'll occasionally need to alter an existing Form or process. Perhaps more data must be collected from the Form, or the process itself must change. Since the process exists, and probably has some in-flight processes already active, you should understand how changing a process or Form definition will affect existing instances.

In general, all process changes are implemented immediately, as soon as the edited process or Form is saved or imported. The change can affect running process instances in various ways. Now, for the most part, changes to a process tend, in actual practice, to be fairly minor. So, in most cases, the change will require no administrative intervention. Process director will apply the change, and any existing processes will simply use the new definition to complete the in-flight process, while retaining the data from tasks that are already completed.

In running processes, the Routing Slip will reflect the tasks that were completed in the old process, as they existed before the change, then subsequently mirror the new process after the point of change. Additionally, Process Director will check the running instances of the process to see if there are any notifications that need to be resent, and, of course, resend the notifications where appropriate. In most cases, therefore, changes to the process will be seamless.

There may be some exceptions, however:

• When you attempt to delete an activity from the Process Timeline definition, if there are any active processes that are currently running that activity, process Director will remove the activity from the dependence tree in the process Timeline definition, but will not delete the activity until all currently running instances of it are complete. Once the users complete the task, Process Director will, in most cases, resume with the next task that was previously scheduled. However, if you delete multiple timeline activities, Process Director may not be able to determine what activity should run next. In that case, the Timeline Instance will be placed in an error state, and will require administrative intervention. Note that for versions of Process Director prior to v5.44, the system will allow you to delete Timeline Activities, but will not try to determine which activity should be invoked next, and place the timeline into an error state immediately.
• When you add new activities to an early stage of the process, any existing instances that have passed the new activities won't return to complete them. The new activity won't run in that instance without some intervention, either administrative, or built into the process, such as by implementing a rollback for instances where the activity results have not been stored.
• When you add a field to a Form, all new instances will store the data properly, but existing instances won't contain any value for the new field. The value will, therefore be "null". In an existing process instance, if that field is used to make a determination of what process activity to start, the system won't evaluate the criteria as expected, which can lead to unpredictable results. For instance, Let's say you add a new Checkbox field to a form called NewField, and, in your process, you add a 'Needed When' condition to a Timeline Activity like "NewField is false". Your assumption might be that, since NewField is a check box and hasn't been marked "true", it must logically be false. But, actually, the field has a null value, because it didn't exist when the form was submitted, and is therefore, neither true nor false. In that case, the field will, when evaluated, fail the condition.
• When you delete a form control from a Form, existing Form instances will retain that data. The Form field will still exist in the Process Director database, even though the control has been removed from the Form's design surface. Always remember, however, that deleting a form control from the Form template will eliminate the control from the Form's display in all Form instances. The data will exist, but the form control won't be displayed, because Forms always display the current version of the Form template. Also, any form conditions that used the deleted field will no longer work once the control is deleted from the form's design surface. Please see the Deleting Controls and Form Fields topic for more information on how to handle Form data from deleted controls by deleting or remapping it.
  

For users of process Director v4.06-5.44, when an Activity is deleted, any process that is running in that Activity will now be placed into an error state. It will remain in an error state until an administrative action is taken, e.g. jump to an activity, start an activity, rollback to a previous activity, etc. Any processes that went into an error state will appear in any Knowledge View that shows processes in error, and users will see a message indicating the reason for going into the error state.

For users of process Director v4.31 or higher, when a new Activity is added to a Timeline Definition, the new Activity will be marked as "Not Required" in any running Timelines if all of its dependencies have already completed.

For users of process Director v4.56 or higher, when a parent Activity is added above existing activities, and there are activities running in existing Timeline instances under that new parent, the system will now automatically start the new parent Activity.

Though Process Director will try to make the Process seamless, in many cases process administrators will still have to intervene in the running processes. To make the intervention easier, you should create a Knowledge View that returns only processes that are in an error state. This will provided you with a list of all the processes that require intervention, making it easier to clear the errors. Similarly, you can create a Knowledge View that displays processes where new activities have been introduced, but which have not been completed in existing instances. In both cases, the Knowledge View feature is your friend.

In general, you shouldn't attempt to create a new Process Timeline when you change a process, unless the change is so fundamental that it constitutes a new process. If the change is that fundamental, then you should recreate the entire application. Otherwise, you should always edit the existing process. Doing so retains the accuracy of your auditing and historical data, whereas creating an entirely new application will have its own, independent data. Depending on your regulatory requirements, you'll still need to retain the old process intact, so that it can be audited, which means keeping an inactive process in your production environment until the regulatory requirement expires.