Previous Next

The simplest approach to reviewing and correcting data within SurveyCTO is to enable the review and correction workflow for a form, choose to hold some or all incoming submissions for review, and then export or publish those submissions for downstream reporting and analysis only once they have been approved. For basic workflows, data is never corrected (it never changes) after being approved and released to downstream users. See the full help topic on the review and correction workflow for more details.

However, you can enable an advanced "un-approve" option when configuring the review and correction workflow for a form (click the Review workflow button for any form in the Form submissions and dataset data section of the Monitor tab, then enable the Allow un-approve and un-reject toggle). If you do so, data that has already been released to downstream users can be un-approved, corrected further, and then re-approved. In such cases, special care must be taken to ensure that downstream users handle the updated data properly.

There are a few reasons why you might want to allow reconsideration of already-approved data. One is that you might discover problems with a submission that hadn't initially been held for review; because such a submission would have been auto-approved on receipt, un-approving would be necessary in order to make any corrections. You might even configure the review and correction workflow not to hold anything for review (i.e., auto-approve everything on receipt) and rely on downstream review processes to flag submissions in need of further scrutiny and correction. Finally, you might manually approve a submission, but then discover additional problems that you wish to resolve. All such workflows are possible, if you enable un-approval.

Accommodating data changes in downstream systems

If an approved submission is un-approved, then it will no longer appear in subsequent exports from the Export tab, or in subsequent API requests. However, if the submission had published into a server dataset, to the cloud, into a Stata dataset, into Microsoft Word or Excel, or into any other downstream system, the un-approved data will remain in those systems. In other words, there is no "claw-back" for published data: once data has been approved and published into downstream systems, SurveyCTO has no way to retract it.

So if a submission is un-approved and then rejected, downstream systems will generally retain a copy of the originally-approved version of the submission. In order to clear approved-then-later-rejected submissions from your systems, you'll need to export rejected submissions and manually remove them from your systems.

If you un-approve a submission, make changes to it, and then re-approve it, it will again be released for export and publishing. What this means is that the (revised) submission will begin appearing again in subsequent data exports and API requests, and it will be re-published into server datasets, to the cloud, into Stata datasets, into Microsoft Word or Excel, etc. Some particular considerations to be aware of:

• Re-publishing to the cloud. If publishing to Google, be sure to configure a unique ID field (usually KEY) so that re-exported data merges into the same rows as previously-exported data; that way, revised data will update prior data rather than coming in as new (duplicate) rows. If using Zapier or webhooks, be sure to configure receiving systems to update existing records or rows, whenever possible, using the unique KEY column. (See this help topic for more...)
• Re-publishing to server datasets. Be sure to configure a unique ID field (usually KEY) so that re-exported data merges into the same rows as previously-exported data; that way, revised data will update prior data rather than coming in as new (duplicate) rows. (See this help topic for more...)
• Re-publishing to Stata. Edit your .do file template to change the overwrite_old_data local macro at the top of the template from 0 to 1. This will overwrite previously-imported data with the latest version included in the export, every time you run the .do file. (See this help topic for more...)
• Re-publishing to Microsoft Word. SurveyCTO Desktop re-runs the mail merge process to re-generate Microsoft Word output with each new export, so revised data should always be included in the latest output. (See this help topic for more...)
• Re-publishing to Microsoft Excel. SurveyCTO Desktop automatically merges on the KEY column when exporting to Microsoft Excel, so new data should automatically merge into workbooks, overwriting old data. (See this help topic for more...)

An alternative to allowing the un-approve option is to carefully review and correct each submission before releasing to downstream systems, then make any later changes directly in those downstream systems (instead of in SurveyCTO).

Previous Next