When you configure due date rules, the due date rule page displays the dates used for the rule in the table at the bottom. The left-hand column shows the order of these dates for the rule.
If you take a rule from a Mosaic form that previously had different names, the table will display a row for each past name of this form. For instance, if you create Form A and name it ‘Assessment form’, then create a new version of Form A and rename it to ‘Assessment form updated’, the table will reflect these changes.
If you use a question from Form A in a due date rule, it displays one row in the table for that form/question when you first add it. If you add another question, it adds another row, and so on.
Once you save and exit completely back to the main configuration tools menu screen, it saves your configuration to the database. At this point, the system finds that Form A has more than one form title. To be helpful, it adds both form titles to the due date rules table, making users aware that this rule could populate from forms with any of the form titles that form has had.
When you return to the due date configuration screen for that rule, you can see two rows relating to this form. Each of these shows one of the two different form titles - Assessment form and Assessment form updated. However, the order number in the first column is the same - if they are used as the first rule, they both show order number 1, indicating that they are actually the same form.
📌 Note: If the question text has changed, each row will also duplicate for the different question texts. This only happens where there are already duplicated lines for a change in form title and not if there is only one form title.
Arguably, the way this is displayed is not ideal, as it is not clear that these both relate to the same form. It might be tempting to remove or make an earlier version of the form inactive, but this will not work because it is not actually referring to a separate thing. As it is the same form and the same question, it will always use that field from any version of the form. This would apply in the same way to any rule, but you will only see it visibly here where the actual form name has been changed.
There is a bug here that due to this issue, you will not be able to make these specific rows ‘inactive’; this will throw an error. We have added this to our backlog. This should not be a big problem, as if you no longer want to use those questions for due date rules, you can delete them. You need to ensure you delete all the rows that refer to the same workstep and question (check for the ones with matching order number). If that leaves no rows in the table, you would need to delete the entire rule from the main table of due date rules.
We also recognise that the screen could be a lot clearer from a user point of view, but unfortunately, we cannot action this at present, due to having many higher priority development items we need to work on, so we hope this guidance will help to manage the screen as it is.
Key pointers:
All versions of a question across all versions of the form will always be used by due date rules, provided it’s the same form ID and same question user code. This is working as expected.
Rows with matching order numbers refer to a single template and question and you should treat them as a single entity.
You must delete rows with matching order numbers, as you cannot make them inactive.
If you delete a row and it has matching order numbers with another, you should delete all the matching rows.
If you prefer a due date rule not to use a question from an earlier version of a form, you need to change the question user code in the new template. This will make it a completely separate question. However, be highly aware of the impact this could have on other aspects, such as form-to-form prepopulation.