Response Editing

MQUAD allows authorized users to edit submitted responses when corrections are needed. All edits are tracked with full version history.

Editing a Response

1. Open the survey and navigate to the Responses tab.
2. Find the response you want to edit (use filters to locate it quickly).
3. Click the response to open it, then click Edit.
4. Modify the desired fields. The form shows the existing values.
5. Optionally add an Edit Reason (recommended for audit compliance).
6. Click Save Changes.

The updated response replaces the previous values in the dataset. The original values are preserved in version history.

Edit Permissions

Not all users can edit responses. Permissions are controlled through:

• Survey-Level Setting — Survey creators can enable/disable editing under Settings > Response Editing > Allow Editing.
• Role-Based Access — The following roles can edit responses by default:
  • Survey Admin — Full edit access on any response in the survey
  • Survey Editor — Can edit responses, but cannot edit approved responses without re-approval
  • Survey Member — No edit access (view only)
• Response-Level Locking — Approved responses can be locked against editing. Toggle Lock Approved Responses in survey settings.

When editing is done, the original respondent is not notified unless Notify Respondent on Edit is enabled.

Audit Trail for Edits

Every edit creates an audit entry with:

• Timestamp — Exact date and time of the edit
• Editor — Who made the change
• Question — Which question was modified
• Old Value — The previous answer
• New Value — The updated answer
• Edit Reason — The reason provided by the editor

To view the audit trail, open the response and click Edit History. Each entry shows the full before-and-after snapshot.

Version History

MQUAD maintains a complete version history for every edited response:

1. Open the response and click Version History.
2. You'll see a timeline of all saved versions.
3. Click any version to view its full snapshot.
4. Click Restore This Version to revert to a previous state.

Version history stores:

• The original submission
• Every subsequent edit
• Who made each change
• The reason for each change

Restoring a previous version creates a new edit entry (it does not delete intermediate versions). This ensures no data is ever lost.

Best Practices

• Always provide an edit reason for audit compliance
• Review the edit history before making further changes to ensure you're working from the correct version
• For sensitive studies, enable Lock Approved Responses to prevent post-approval modifications
• Use bulk edit mode for applying the same correction across multiple responses (e.g., fixing a consistent data entry error)