Entity update happens without approval

[Mauricio_Andres_Arci]

1. What is the issue? Please be detailed.
I want to present the following example and ask for your help on a possible solution to the workflow that I need.

I create a list of entities named patients, which is fed through a csv file, from the csv file I load the label, id and name of the patient. I create empty fields 'pres_dose' and 'adm_dose' which I will feed with two formats at different times.

In the image is shown the configuration of the list of entities patients regarding the creation and update will be done until a person reviews the data. However, when I use the Follow_1 and Follow_2 formats, which populate the 'pres_dose' and 'adm_dose' fields, the fields are populated in the entity patients without the approval, which I show in the images of the data collected by the Follow_1 and Follow_2 formats.

I would like the fields to be populated only when the records are marked as approved.

I would appreciate your help on how I could achieve this.

2. What steps can we take to reproduce this issue?

1. Create patients entitie list with the indicated fields.
2. Mark the field 'Create Entities when Submissions are marked as Approved' entity settings.
3. Upload de data of patients.csv file.
4. Upload the attached forms.
   5 Fill out the forms.
5. Entity update happens without approval.

3. What have you tried to fix the issue?
Create independent entitie in each follow after approval, but I would like to have only one list of entities.

4. Upload any forms or screenshots you can share publicly below.
Attached are the evidences
patients.csv (112 Bytes)
Form_follow_1.xlsx (576.2 KB)
Form_follow_2.xlsx (575.9 KB)

[LN]

Thanks so much for all the detail you've provided on your scenario, that really helps make it clear what you're trying to achieve!

Currently, it's only possible to require submission approval for Entity creation, not for Entity updates. The biggest reason we don't support approval/rejection of updates is because in many cases the order that updates need to be applied in matters. This is not the case for your scenario but it is a common case.

Can you tell us more about what happens in your workflow after the two fields are populated? Why is it important for those fields to be reviewed?

Choice filter to only include Entities of interest in follow-up

If it's because something about their presence or value determines whether the related Entity is eligible for a next step, you should be able to use form design to address the need.

For example, if you start your next step with a select_one_from_file patients.csv, you can add a choice filter of

pres_dose != '' and adm_dose != ''

so that only patients who have received those doses are shown.

Similarly, if you're only interested in patients with doses above a threshold of .6, you could use a choice_filter of

pres_dose > 0.6 and adm_dose > 0.6

Choice filter to only include reviewed Entities in follow-up

If you really need a human to review the values entered, you could add another Entity property to represent this requirement. For example, you could introduce a reviewer_initials property so that whoever reviews the updates can initial the Entity.

Then you have some options for how to capture those initials. You could have reviewers use Central to view Entity data from the table, edit an Entity, and add their initials. Alternately, you could have another form that only reviewers have access to that allows them to view and modify the does values and then enter their initials. You could use the existing property values as defaults or you may be interested in some of the ideas from this thread on presenting Entity property values.

Your other follow-up forms could hide Entities that don't yet have reviewer initials with a choice filter:

reviewer_initials != ''

Hopefully one of these two concepts is helpful to you. Consider providing more detail on what comes after the two initial follow-ups if you'd like other ideas.

[Mauricio_Andres_Arci]

Thank you very much Helen for your prompt response and for the series of possibilities you gave me.

I will now try to expand on the actual workflow scenario, clarifying the reasons why I require prior approval for the entity update, as the scenario I posed in the example was somewhat simplified but served for illustrative purposes.

In the actual scenario, after uploading the data to patients.csv, there are three stages. In stage 1, person A fills out the form to obtain the value that will update the pres_dose field in the patients.csv dataset, I would need that only once approved by person A, for quality, security and traceability reasons, the pres_dose field would be updated, since this would guarantee person B, in stage 2, using choice filter with the condition ${pres_dose}!='', that person B will only be able to select those patients that have been approved by person A. In stage 2, person B fills in the form that updates a field called prod_dose in the dataset, once filled in, for quality, security and traceability reasons, person C verifies and approves, thus updating the prod_dose field in the dataset. Finally, in stage 3, person D, will make use of the patient data only approved by person C using the condition ${prod_dose}!='' and the format will lead to update the adm_dose field, which would be the last field in the workflow sequence and that in principle I do not propose to require revision on the latter.

I thank you for the proposals you gave me, on which I will have to take one of the following routes in my scenario, which I order from most to least liked:
1. Based on the second part of the second proposal, I should guarantee the access of persons A and C as supervisors to the list of entities in ODK Central, so that they can edit the lists of entities, however, although this would allow me to achieve to have the adequate filters in the following stages and have the initials of the person who checked, this is not as elegant as ODK's default status check, but it would work.
2. Based on the first part of the second proposal, it would imply having two additional formats, one for review and approval between stages 1 and 2 (which only person A has access to) and another for review and approval between stages 2 and 3 (to which only person C has access), however, this would allow me to achieve having the proper filters in the following stages, facilitate the workflow and minimize possibility of errors due to duplicates.
3. Creating a new dataset at each stage would make it easier for me to approve the formats, which would be done directly without additional formats, but I would not manage to establish the series of filters that are raised and that would significantly facilitate the workflow.

I am immensely grateful to the team for the progress they have made on ODK, as it allows us to incorporate it into more complex workflows.

[LN]

Thanks for those additional details!

With the information I have, I would tend to go for option 2 with the specialized approval forms but I agree option 1 would work as well.

Since it sounds like person A is both entering and verifying the first collected value, maybe you could also do both steps in the first form? For example, you could have a field to capture the value and then a second one to confirm it. You could have text like "I certify that the value is ${value}" and capture the person's initials. Of course, this would not work if review and approval require some other source of information that's not available at initial capture time.