This issue occurs in very specific scenarios. We expect that the majority of customers will not experience this issue, as workflow and form design and local practice would prevent it in most cases.
This issue occurs where a form is prepopulating a multi-subjects table but the pre-population sources are inconsistent - so one of the columns is not populated from one of the source forms for the other columns. It only occurs where the source form is the one that is missing a column and the relevant table is left blank (no rows created) in that source form.
An example:
Initial Child Protection Conference (ICPC) form contains a multi-subjects table for a child's plan but does not contain an Update column.
The Review conference (RCPC) form and Child's Plan form contain the same table but do have the Update column.
The record has had a previous child protection workflow so there are earlier RCPC/Child's plan forms.
All pre-population is 'Last completed' and the three forms all populate from each other.
The Update column is only pre-populated from Child's plan and RCPC as the ICPC does not contain the Update column.
You have completed an ICPC on the case and are now attempting to start work on the Child's plan.
The relevant table in the ICPC has been left blank (otherwise this issue does not occur).
What happens is that the Child's plan populates all the columns apart from the Update column and then goes to try and populate the Update column from the previous Child's Plan or RCPC. This results in an orphaned row, as it only brings through the Update column with no subject(s) to link it to. This always happened, but previously the row was just not visible. A recently introduced check relating to removing a person from a group workstep means that this orphaned row now causes the form to crash.
NB - this is an example - there could be more source forms, columns, etc, but the same principles apply.
This defect will be fixed in Mosaic 22.2. Prior to that, workarounds are available as below:
Optional workaround for non-CP worksteps
Re-open the previous workstep and ensure the relevant tables all have at least one row added.
Save and finish and then start the workstep that was crashing, this should now start fine.
Workaround for CP worksteps or to avoid re-opening and changing earlier worksteps
Create a new form, Workaround form, containing a multi-subjects table with just two columns, the auto-created subjects column and a column with just a check-box.
Create a new workflow step Workaround step with a single step containing the Workaround form and a terminating next action.
Set permissions for this workstep to only be those who would need to perform the fix. We recommend this is just system administrators, as if this is used where it is not required, it could result in information not populating when it should.
Identify the multi-subjects table or tables that fit the scenario above, with inconsistent sources within that table. So in my example that would be the RCPC and Child's plan forms. Add the Workaround form as an extra source for these tables - just for the subjects column.
Only on records that have had the crash when starting a workstep in this scenario create the new Workaround step - create one row in the table, select all subjects, check the check box and finish the step with the next action.
The crashing workstep will now open.
Important to note:
This should be thoroughly tested locally prior to use.
This should only be used where the crash has happened as this will mean that the source workstep for that table is empty. If it is used in other situations then it could stop the workstep from pre-populating important information.
Where more than one table is affected in a single form, there are a couple of options:
Use the workaround form as above and use the single table as a source for all the affected tables. This would have a high risk of information not being populated, as it would clear all the tables for which it was a source. Users would need to be made aware of this and check previous forms for information.
Create separate Workaround forms for each of the affected tables. Check the previous form (the ICPC in my example) to find out which of the tables are blank (have no rows created at all) and create the relevant Workaround form for that table.
In order to avoid these crashes happening, we recommend that you review the workflow design. Ensure multi-subjects tables have consistent sources where possible. In the example given, the ICPC was not pre-populated from anywhere else so any table rows would be new. In that case you could add an Update column that was set to not visible in the ICPC step and use that for pre-population to avoid the issue.
This should only be used when that column is not pre-populated though. If it is pre-populated then information could be missed and then unknowingly populated later on. In that case the column can be added and left visible and local advice provided to workers on how to use this.
This, however, will not prevent occurrences of the problem for cases where the source form, ICPC in the example, has already been created.