Allow Invalid Checkpoints to Be Resumed

When an interview attempts to resume a checkpoint that was saved in a previous version of a policy model, in a later version of the same policy model which has changed making the original data invalid, you have two options for how you would like the interview to behave:

Drop any invalid data (that is, data that doesn’t fit with the new model) and resume the interview from a saved checkpoint with as much information as possible still loaded into the interview session. This is the default behavior for new projects in 12.2.14 19A onwards.
Keep the invalid data and the interview fails to resume. In other words, the interview will only resume if all the data is valid and can be loaded. This is the default behavior for 12.2.13 18D and earlier projects, including upgraded projects.

Invalid data includes any data which would have normally thrown an error and prevented a resume operation. If the checkpoint file has been modified manually by someone and is missing files or has invalid XML this will still throw an error. This feature only deals with data which is valid to the original policy model but invalid in another iteration of the policy model. Examples of changes resulting in invalid data are when:

an attribute has been removed
an attribute type has changed
a selected enumeration value no longer exists
there is a reference relationship between existing and non-existing entities
a containment relationship type has changed
an attachment exists for a control that no longer exists or the file type is no longer acceptable
a signature exists for an entity which no longer exists
a user set entity has become an inferred entity
an inferred entity has become user set
a screen has changed entity context

To allow invalid checkpoints to be resumed in an interview (that is, to drop any invalid data and resume the interview where possible):

On the Interview tab, click the Checkpoints button.
In the drop-down window, deselect the option Resume only if all data can be loaded.