Guide to case management part 4: Case management workflows

This article is part 4 of our series on case management. See the bottom of this article for the other parts in this series. You can also check out our webinar on case management; skip to 19:48 to learn about case management workflows, including how to publish data to and retrieve data from case management server datasets.

In this article, we discuss how to identify form submissions as being part of a case, and how to publish to and pull data from the cases server dataset.

The "caseid" field

When you open a form via a case, the "caseid" field will have the same value as the id of the case. For example, if a form is opened from the case with an id value of 1001, then "caseid" will have a value of 1001. This is helpful in data analysis for identifying which case a form submission relates to.

If you are publishing to the cases dataset, this will be helpful for publishing to the case you are currently working on. We'll get to that more in Publishing data to cases below.

If a form is not opened from a case (i.e. opened from Fill Blank Form instead), then the "caseid" value will be empty. This can be used in a note field to prevent a user from opening a form outside of a case. Check out this sample form for an example.

This form was opened from the case with an id value of "complaint-138", so it has a "caseid" value of "complaint-138".

Cases dataset as a server dataset

The case management dataset is a server dataset, so your forms can pre-load data from it, and also publish form submissions into it. You can even add additional columns to the dataset that are not directly related to case management. For example, in the example case management system in part 7, there are columns for 'complaint_date', 'complaint', 'severity', and more. None of these are needed for case management, but they are used by the form, and it makes sense to store them in the same server dataset. Of course, if you prefer, you can also store this data in a separate server dataset.

You can even display this extra data in the case management table view. For example, if it is more convenient to identify cases by phone number, you can add the phone number column to the cases table.

If you are not familiar with server datasets, check out our support article on using data in another form, which lists several resources you can use for publishing to and pulling from a server dataset.

In addition to the columns needed for a cases dataset, this server dataset stores data about the date 'complaint_date', 'complaint', 'severity', and a lot more.

Publishing data to cases

Publishing data from form submissions can be used for both adding a new case and updating an existing case (as discussed in part 2). If you are using form publishing to update an existing case, make sure the unique identifier (aka the Form field to identify unique records) is the field that publishes into the 'id' column (usually the "caseid" field, more on that below). If the value of that unique identifier does not exist in the 'id' column of the server dataset, then the new data will be published as a new case in a new row of the server dataset. If the 'id' value does exist, it will update the case with that id value. If you are using form publishing just to create new cases, not update cases, there is no need to identify the unique identifier.

If you are publishing to the same case the form was opened from, make sure the Form field to identify unique records is the "caseid" field, and make sure the "caseid" field publishes to the 'id' column. That way, the form can update its own case. For example, if you open a form from the case with an 'id' value of 1001, and you would like the data from that form to be published to its row in the cases dataset, the field "caseid" will have a value of 1001, so it would publish to the row with an 'id' value of 1001, therefore updating its own case.

For example, in the example case management workflow (we'll talk about that more later), the cases dataset not only stores case data, but it also stores complaint date, complaint information, visit number, and a lot more. As data needs to be updated (such as the number of times the respondent has been called needs to be increased), the form publishes that new data to its row in the server dataset.

A great, practical example that is frequently used is our CATI starter kit. In that system, the cases dataset not only stores case data, but stores the number of times the respondent has been called, their phone numbers, and a lot more. Once you are comfortable with case management, feel free to check out our CATI system.

To learn more about dataset publishing, pulling that data into another form, and recommended settings to make sure collection devices are always downloading the latest data, check out our support article on using data in another form.

This is the dataset publishing mapping for the form with the ID "complaint_followup" into the server dataset "cases". The "caseid" field publishes into the 'id' column, and the Form field to identify unique records is the field "caseid".

Offline cases and data

Advanced offline feature

This is an Advanced offline feature. Upgrade your price plan to include these features or contact our Sales team to discuss an enterprise agreement.

Using data from another form

If your cases dataset has Allow offline updates enabled, and you publish form data to the cases dataset, then that data will be available for pre-loading immediately (as discussed in part 3.2 of Using data in another form).

Creating and filling out new cases

Newly created cases can also be worked on immediately if Allow offline updates is enabled. If you fill out a form that adds a new row to the cases dataset through dataset publishing, that new case will appear in the Manage Cases menu, ready to be opened and completed. You can even transfer those cases to other collection devices so other enumerators can work on them, as discussed in part 3, section Transferring cases.

Optional: Closing cases (aka hiding a case from data collectors)

If you would like cases to no longer be visible to any data collectors once they've been closed/completed, you can change the users or roles value to a username or role that does not exist. For example, when a case is considered complete, the form instance can be set up to publish "complete" to either the 'users' or 'roles' column of that case row. Since there is no username or user role called "complete", the case will not be visible to any data collectors in the Manage Cases menu. This method is used in the CATI starter kit.

If you prefer, you can also hide a case without submitting a form instance by manually changing the 'users' or 'roles' value of the case. Just like any other server dataset, you can do so either by using the Edit button for the server dataset to directly edit the case, or by using the Upload button to upload an updated cases CSV file to the server dataset (see part 2 of this guide). As long as the 'users' or 'roles' column has a value that is not an actual username or user role, then that case will not be visible in the case management menu.

To learn more about publishing, check out Publishing data to cases above.

Case 1002 has a users value of "closed". Since there is no username called "closed", this case will not appear to any users.

You can also close cases by publishing to the enumerators property instead of the users or roles property, which will also hide those cases. You can learn more about enumerator functionality in case management in part 2.

While it is possible to hide cases by deleting them from the server dataset, this is not advisable, since that server dataset data may be needed later. It may be needed for later analysis, checked for an audit to make sure the correct data is being published and pulled, pulled by another form for data collection or auditing, or for whatever other reason you may need it. By closing a case using the users or roles values, the data will still be in the server dataset, but invisible to data collectors.

If you really do want to delete that row of data, on the Design tab, go to the server dataset, click Edit, go to the row you would like to delete, click Delete, and confirm the deletion. Keep in mind there is no "undo" for deleting server dataset rows, so it is a good idea to download the dataset data before deleting any rows.