January 6, 2022
Production Change Request Guidance
When your REDCap project is in PRODUCTION, changes made in DRAFT mode and some changes are not effective immediately. All "critical" edits are reviewed and approved by an ERIS REDCap Administrator. This is to ensure that data which has already been collected is not deleted, re-coded or overwritten unintentionally.
Please allow 2-5 business days for your CRITICAL changes to be reviewed and approved by a REDCap Admin.
Longitudinal Production Changes
Adding or modifying longitudinal events can be completed by a project user with "Project Design & Setup" user rights. Deleting events can only be completed by a REDCap Administrator. Email firstname.lastname@example.org to request deleting events.
Data Collection Instrument Changes
Listed below are types of changes and data impact.
Requester should be aware that changes to any variables may affect programmed calculations and/or branching logic. It is the responsibility of the requester to review and test all calculated fields and branching logic prior to submitting changes. The impact to these fields will NOT be tested by ERIS REDCap Admins.
Revision Report – report created in Report Builder within your project by an ERIS REDCap Admin to review requested changes.
Critical Issues – these types of changes cannot be automatically approved by the system. They must be reviewed in detail by ERIS REDCap Admins.
|Metadata||Change Type||Data Impact||Require User Confirmation||REDCap Admin Action||Critical Issue|
|Variable / Field Name||Add new||No data impact. New field will be added to all records.||No||Commit changes.|
|Variable / Field Name||Delete||Possible data loss. Deletes the field and ALL the data entered for that field||Yes, if field contains data.
No, if field does not contain any data.
|Run Revision Report to verify if field contains data. If field has data, notify requester for confirmation prior to committing changes.||critical|
|Variable / Field Name||Rename||Possible data loss. REDCap views this action as the equivalent to deleting a variable and adding a new variable. Data is deleted||Yes. Same as deleting variable / field name.||Same as deleting variable / field name.||critical|
|Form Name||Add new form||No data impact. New form/fields will be added to all records.||No||Commit changes.|
''Note: Form name “back end” name (data dictionary ex:"baseline_data") does not appear on screen
Form label “front end” name displays on screen (ex: "Baseline Data")
|Rename form||Possible data loss. The data dictionary renames the form name. All form status values (unverified, complete) for ALL records will be reset to “Incomplete”.
The Online Form Editor will NOT change the form name and only renames the form label, preserving the form status for all records.
|Yes, if changing form name using data dictionary.
No, if only changing form label using Online Form Editor
|Check if FORM_complete field is being deleted.
If yes, warn user that all form statuses will be deleted. After receiving acknowledgement, commit changes.
If FORM_complete field is not being deleted, commit changes.
|Field Units||Add, Modify, Delete||Changes field unit label. Label is not displayed on form.||No.||Commit changes.|
|Section Header||Add, Modify, Delete||Not directly associated to any data collection variable. Descriptive text.||No.||Commit changes.|
|Field Type||Modify||Possible data loss. Depending on the change, data can be deleted.
Examples of changes that can be made without data loss: Radio buttons to drop downs; Drop downs to Radio buttons
Examples of changes that can be made with data loss: Radio buttons to check boxes; Text box to calculated field
|Yes, unless change can be made without data loss.||Run Revision Report to verify if field contains any data and note format. If data saved will be deleted, notify requester for confirmation prior to committing changes.||critical|
|Field Label||Modify||Possible label mismatch. Change to question caption may change the meaning of data previously entered (ex: changing "happy" to "unhappy").
Examples of changes that do not require confirmation: Spelling corrections Format changes
|Yes, if meaning is thought to differ from original label and there is data saved for the variable.
No, if minor updates (spelling corrections)
|Review label text and if any question as to change in meaning, run Revision Report. If data saved for field label, review meaning change impact with requester.||critical|
|Choices (codes)||Add||No data impact. New choice will be added to all records.||No||Commit changes.|
|Choices (codes)||Delete||Possible data loss. Deletes the choice and ALL data entered as that choice||Yes, if field contains choice code.
No, if field does not contain the choice code.
|Run Revision Report to verify if field contains data and the code. If field has the code, notify requester for confirmation prior to committing changes.||critical|
|Choices (codes)||Recode||Possible label mismatch. Codes are not automatically re-mapped to new codes. Data entered remains the same in the database. Relabeling codes may change the meaning of data entered.||Yes, if data has been collected.
No, if field does not contain any choices being recoded.
|Run Revision Report to verify if field contains data and the codes. If field contains code choices, notify requester for confirmation prior to committing changes.||critical|
|Calculations||Add, Modify, Delete||Forms with saved calculated field values will not automatically recalculate when changes are committed. Values should be derived and confirmed in analysis. And all forms with values should be resaved to update stored values.||Yes.||Warn requester that all values previously calculated will not automatically update. After receiving acknowledgement, commit changes.|
|Slider Labels||Add, Modify, Delete||No data impact. Display only. Slider scale is coded as 0-100||No.||Commit changes.|
|Field Note||Add, Modify, Delete||No direct data impact. Descriptive text.||No.||Commit changes.|
|Text Validation Type||Add, Modify||Possible data loss. Data entered as free text or other type of validation text, may no longer be valid||Yes, if previously entered data becomes invalid.
No, if validation change maintains data integrity.
|Run Revision Report to verify if field contains data. If so, request confirmation prior to committing changes.||critical|
|Text Validation Type||Delete||Field becomes open text field.||No.||Commit changes.|
|Show Slider Number||Add, Delete||No data impact. Display only. Slider scale is coded as 0-100||No.||Commit changes.|
|Text Validation Min||Add, Modify, Delete||No data impact since out of range data can still be saved.||No.||Commit changes.|
|Text Validation Max||Add, Modify, Delete||No data impact since out of range data can still be saved.||No.||Commit changes.|
|Identifier?||Add, Delete||No direct data impact.||No.||Commit changes.|
|Branching Logic||Add, Modify||Possible data loss. Fields that will be now be hidden due to updated logic that already contains data will prompt to erase data.||Yes||Warn requester that fields previously not hidden that contain data will prompt to erase data if now included in branching logic. After receiving acknowledgement, commit changes.|
|Branching Logic||Delete||No direct data impact (may impact missing data analysis). Fields will always be visible||No.||Commit changes.|
|Required Field||Add, Delete||No data impact since data can still be saved without completion of required fields.||No.||Commit changes.|
|Custom Alignment||Modify||No direct data impact. Display only.||No.||Commit changes.|
|Question Number (surveys only)||Modify||No direct data impact. Display only.||No.||Commit changes.|
|Matrix Group Name||Add, Modify, Delete||No direct data impact. Display only.||No.||Commit changes.|
If it is absolutely necessary for you to make changes to a project in production there are a few methods you can use to ensure the project won't lose data or be irreversibly changed.
- Running Exports
- By going into "Data Exports, Reports, and Stats" and running an export of all data you will have a back up of all data incase the changes delete or orphan your data incidentally
- Request a Copy of Project
- In the "Other Functionality" page you can request a copy of your project. You can create an exact copy with all data, reports, user roles, etc. to attempt changes on. This way any mistakes will not change the actual project
- Dictionary Snapshots
- Within the online designer you can take a "Snap Shot of the Instruments." You can then go into the project revision history page to download the instruments as they where when the snapshot was taken and adjust the project accordingly
- Lastly users can go to the other functionality page and download a backup of the entire project (download metadata) before you make any changes
Utilizing these methods will be useful in making sure projects are successfully backed up just incase any changes cause undesired results.