How to Remove an Element from a Form
Elements that are no longer needed on a form can be removed. There are 2 methods for the removal of elements from a form:
How to Select a Removal Method
The method used to delete an element will depend on when the element was added to the form.
On forms that are being developed and have never been used, you can delete the elements completely as they shouldn’t contain important or historical data.
Once a form is in use and data has been entered into the input elements, you must start to consider data retention when removing elements from a form. Elements that are deleted will have their data made inaccessible for use in platform features such as search, as well as in reports.
For those reasons, form that are already in use should only have newly added elements deleted. If you aren’t sure if your users are already entering data into an element, it is always best to err on the side of caution and hide the element instead of deleting it.
All other fields that need to be removed from the form should be hidden instead of deleted.
How to Remove Elements via Hiding
Hiding an element as a method of removal involves creating a Historical Field Container and moving elements into that container.
Creating a Historical Field Container
A Historical Field Container is a normal container, placed to the right of the primary Tabset and styled to identify its purpose. It is possible that a form will already have this container, in which case this step can be skipped.
Create a container to the right of the your primary Tabset. The vertical position does not matter, but ideally the container is as wide as your primary Tabset.
Apply the following attributes to the container.
||Historical Field Container
||visibility: hidden; border: 3px solid tomato; background: mistyrose;
- Your new container should look like the image below.
Depending on the number of elements being hidden, you may want to add some structure to your Historical Field Container. If this is the case, create a child container and apply the following attribute to the container.
||<Name of Tab>
||border: 1px solid tomato;
Moving Elements into the Historical Field Container
Moving elements into the Historical Field Container works the same as moving elements in other parts of the form.
When elements are moved into the Historical Field Container, they should be checked for the following attributes:
Optional to Remove
These attributes should be removed, depending on your business need. Users often find it difficult to understand when a hidden element is visible in the Dashboard. If you need to have this information available, you should indicate that the element has been marked that the element isn’t visible by appending “(Historical)” or “(Depreciated)” to the end of the element description.
Searchable: If this attribute isn’t removed from an element, the removed element will be visible in Dashboard Listings card and many other places.
dashboardMetric* attributes: If these attributes aren’t removed from an element, information about the data they contain will be displayed in the Metrics card on the Dashboard.
Must be Removed
These attributes must be updated because they will cause historical elements to update data on the form or affect the functionality of the form.
bulkDataEntry: If this attribute isn’t removed from an element, the removed element will be able to be updated using the Bulk Data Entry module or during a Record Rollover.
isRequired: If this attribute isn’t removed from an element, then all new records will never be able to reach 100% completion because they will not have access to edit all required elements.
SIS* attributes and GDI* attributes: If these attributes aren’t removed from an element, then when a user imports data into a record, they will also be updating these hidden elements.
An example of this would be if after-tab-load = “$(this).updateVal(player.userId);”
Update the attribute to after-tab-load = “// $(this).updateVal(player.userId);”
class = sliderControl : If an element has the class sliderControl applied, it should be removed. sliderControl elements are utilized by the clevrShowHide feature and can cause erratic behaviour if placed in a hidden container.
How to Remove Elements via Deletion
Deleting an element as a method of removal is relatively simple compared to Hiding. Deleting an element is an irreversible action, and should only be performed when you are fully confident that the selected elements are not needed.
First, select the element you would like to delete.
In the Accordion Menu > Options Table, click on “Delete selected”.
You will be prompted to confirm you would like to delete the element.
The select element should now be removed. Once the form is published with an element deleted, there is no way to recover that element and the data it stored.
If you accidentally delete an element, you should immediately Discard.
When should Elements be Removed
The removal of elements should align with the cyclical nature of the form; this will often align with the record rollover process for the form. If the form has no obvious cycle, then performing the removal should occur during a less busy time of year for the form, such as during the winter, summer, or March break.
The removal of elements should be performed before a Record Rollover. This order of operations is critical for a proper Record Rollover, because Record Rollover clears the flagged elements in the new or cloned records. In the situation where the removal occurred after the Record Rollover, the hidden fields will contain data from previous records, which can have the following effects:
The data will appear in the reports of the new records, even though it won’t be visible or editable in the new record.
If a removed element is kept available for search, the data may appear in the Listings and Metric cards on the dashboard without being visible in the record.
In situations where elements should no longer be used by form users outside of this cycle. The elements should be disabled, grouped, and marked as part of a historical data section of the form. The historical section can then be removed via hiding when appropriate.
When removing input elements from a form and considering updates to affected reports, it is important to consider what will appear on the report for historical records. Removing a hidden input element from a report will mean that if a user generates a report for a historical record, the data will not appear in that report and will not accurately reflect the data contained in the record; which will affect the integrity of the report.
To maintain the integrity of your reports while removing elements, you have two options:
Use logic tags in the report to only show the removed elements if the element has data. This will allow the report to properly display the data stored in historical records, while not displaying removed sections and labels on newer records that would not have data stored. If the removal of an element is properly timed and executed, as mentioned above, newly created records will not have data stored in the removed elements and the section on the report will not appear for those records.
Create a copy of the report and perform all updates on the new copy.
Adding the valid school years to the report’s name is a valid way of indicating which report aligns with which records.
Historical reports can be deactivated to reduce the number of reports visible to users, without actually losing the historical version of the report. When needed, the historical report can be reactivated.
Always ensure that DoNotClone is applied to all elements that are hidden, either by directly applying the attribute to the element or by applying the attribute to a parent element. There is never a situation where a removed element should be allowed to clone.