Admin Tools & Data Maintenance
Items on the tools menu control rarely accessed but important setup and configuration tools for OPSCOM. Data Maintenance options are also here.
- Data Maintenance Articles
- Using the Database Importer (Beta)
- Importer Field Descriptions
- Create or Refresh a Preview Space
- Resolve Duplicate Options
- History Search
- Purge Old - Explained
- Purging Incidents
- Handheld Devices and Commons
- Managing Recurring and Onetime System Tasks
Data Maintenance Articles
The Data Maintenance tools and processes allow administrators to clean, merge, and archive system records. The primary purpose of these features is to ensure optimal system performance, data accuracy, and ongoing regulatory compliance by eliminating redundancies and outdated information. This article is intended for OPS-COM administrators who are responsible for maintaining overall system health and data integrity.
Setup and Configuration
These maintenance activities do not require a specific initial setup, but they do require high-level administrative access to execute.
Admin Side: Administrators must be granted the appropriate user role permissions within the system settings to access sensitive data management tools, such as purging records, merging accounts, or importing bulk user data.
User Side: These features are strictly backend administrative tools and are not accessible to end-users on the portal.
Using this Feature
Administrators can utilize a variety of tools to maintain their system data. Because data maintenance is a broad category, the specific steps will vary based on the task you are trying to accomplish.
Benefits of Routine Data Maintenance
Keeping your system data well-organized provides several key operational benefits:
-
Improve Data Accuracy: Identifying and correcting errors, inconsistencies, and redundancies ensures that the information your staff relies on is trustworthy and precise.
-
Enhance System Performance: Clean data leads to faster processing, quicker searches, and more efficient operations within the system, preventing slowdowns during peak usage times.
-
Facilitate Informed Decision-Making: Accurate and up-to-date data provides a clear and reliable foundation for financial analysis, reporting, and strategic planning.
-
Ensure Compliance and Security: Maintaining data integrity helps your organization meet regulatory compliance requirements and reduces the risk of security vulnerabilities associated with outdated information.
-
Reduce Operational Costs: Minimizing errors improves administrative efficiency, helping to avoid costly reworks and resource waste.
Available Data Maintenance Workflows
To perform specific maintenance tasks, please review the step-by-step instructions in the following detailed guides:
Exercise extreme caution when using data maintenance tools like the system purge or user merge functions. These actions are often irreversible. If you are unsure about the impact of a specific maintenance task, contact OPS-COM support for guidance before proceeding.
Best Practices and Considerations
-
Establish a regular maintenance schedule: Organizations should establish a routine schedule for data maintenance activities. Performing routine cleanups, such as purging old records or merging duplicate users, prevents the database from becoming bloated and keeps the system running smoothly.
-
Verify data before executing permanent actions: Always verify your data and adhere to local retention policies before executing a permanent merge or purge. Because many data maintenance actions permanently alter or remove records from the database, administrators must ensure they are not accidentally deleting active user data or historical financial records required for compliance.
Using the Database Importer (Beta)
The Database Importer provides administrators with a powerful tool to import bulk data into the system using CSV files. Its primary purpose is to facilitate initial data migrations, execute mass record updates, and integrate data from external systems to ensure your database is populated efficiently. This article is intended for OPS-COM administrators responsible for backend data management.
Setup and Configuration
This feature requires specific administrative permissions to access and operate the import tools.
Admin Side: Administrators must have the appropriate permissions enabled under the Systems tab of the permissions management page. For complete instructions on modifying user access, refer to the Manage Roles and Permissions wiki article.
-
Manage tables: Enables the user to view the manage tables page and utilize the upload functionality for importing data. It does not grant the ability to reset or purge tables.
-
Reset tables: Grants the ability to empty or reset tables. This requires the Manage tables permission to be enabled as well so the user can access the page.
Using this Feature
Administrators can use the following instructions to upload CSV files, match data columns, and initiate the import process.
Accessing the Importer
-
Hover over Tools and click Data Importer - BETA to access the main management screen.
Importing Data into a Table
-
Click the Upload button next to the desired destination table.
-
Select your comma-differentiated or semi-colon-differentiated CSV file from the modal window.
-
Click the Submit button to begin the file upload and proceed to the table import screen.
-
Match the columns from your imported CSV file to the corresponding destination columns within the system. The system will automatically pre-select matches if your CSV contains recognized column names.
-
Click the Process button to initiate the background import process.
The importer has a strict limit of 10,000 records per batch import. This maximum count includes your CSV header row.
Resetting a Table
The Database Importer also allows administrators to completely purge an entire table's contents.
-
Click the Reset button next to the specific table you wish to empty.
-
Type DELETE into the confirmation text field in the modal window.
-
Click the Delete button to permanently purge all records from the selected table.
Resetting a table is an irreversible, permanent action. Once the data is deleted, it cannot be recovered. Additionally, purging primary tables (like vehicles or permits) will automatically purge closely connected join tables (like vehicle joins or permit joins).
Order of Operations for Related Imports
Imports that contain related information must generally be executed in a specific order to ensure dependencies are met and records associate correctly.
| Table to Import | Requires Prior Import | Notes |
| UserProfile | None | This should generally be the first table imported. |
| Vehicles | UserProfile | Ensures the user record exists so the vehicle can associate via a join record. |
| OffenceLocations | None | Must be imported prior to violations for proper location marking. |
| Permits | Vehicles, UserProfile | Ensures vehicle and user records exist for permit associations and automated payment marking. |
| Violations | Vehicles, UserProfile, OffenceLocations | A violation requires an existing vehicle record to be created, and an existing location to be marked properly. |
Unique Identifiers and Duplicate Settings
When importing data, the system uses specific unique identifier columns to determine if a record already exists. If a match is found, the system will follow your selected duplicate setting to either ignore the duplicate (do nothing) or overwrite the existing record with the new CSV data.
-
UserProfile: Uses UserUUID or Email. If both are supplied, UserUUID takes precedence.
-
OffenceLocations: Uses LocationName.
-
Vehicle: Uses Plate.
-
Permits: Uses both PermitNo and LotNameID. Both are required, meaning identical permit numbers can exist if they are assigned to different lots.
-
Violations: Uses Ticket.
| Inserting Into Table | Column Inserting Into | Sourced From Table |
| UserProfile | prov | Provinces |
| UserProfile | UserTypeID | UserTypes |
| Vehicle | ProvID | Provinces |
| Vehicle | ColourID | VehicleColours |
| Vehicle | MakeID | VehicleMake |
| Vehicle | TypeID | VehicleType |
| Vehicle | PlateTypeID | VehiclePlateType |
| Permits | LotNameID | LotName |
| Permits | StateID | PermitState |
| Violations | VehicleID | Vehicle |
| Violations | TicketType | TicketCategory |
| Violations | LocationID | OffenceLocations |
Understanding Post Import Processing
After data is inserted into the base table, the system runs separate, automated post-processing to establish relationships.
-
Status Emails: You will receive a first email confirming the rows inserted into the temporary table, and a second email detailing the final records updated, inserted, and post-processed.
-
Permits: Permits are automatically booked to associated users. If selected during import, these permits will automatically be marked as paid; otherwise, they are sent to the user's cart.
-
UserProfile: Users without a specified login source default to OPSCOM and are automatically set to enabled.
-
Vehicle: Vehicles are automatically associated with matched users. Matched alerts will attach to the vehicle, flagging it on your hotlist.
-
Violations: Violations missing an issued or due date will have one automatically generated at the time of import.
Best Practices and Considerations
-
Preserve leading zeros in Excel: Force Excel to treat cells as text before converting to a CSV to prevent it from dropping leading zeros on IDs. Open a new sheet, type
="'"&and click the target cell from your original sheet (e.g.,="'"&A1). Drag the formula across your data to add an apostrophe in front of all values, then save this new sheet as your CSV. -
Align user association identifiers: Ensure you select the exact same unique identifier (UserUUID or Email) for both the primary user record and any associated records. Mixing identifiers between the user profile import and the vehicle/permit imports will cause post-processing associations to fail.
-
Review column formatting thoroughly: Always cross-reference your CSV headers with the official data requirements. For detailed information on each column's purpose, whether it is required, and specific formatting rules, review the Importer Field Descriptions guide prior to uploading.
Importer Field Descriptions
The Importer Field Descriptions article provides a comprehensive reference guide to the data fields used within the Using the Database Importer (Beta) tool. Its primary purpose is to help administrators successfully prepare CSV files by detailing column names, internal system names, requirement levels, and data types for each supported table. This article is intended for OPS-COM administrators responsible for large-scale data migrations or updates.
Setup and Configuration
Preparing for a successful data import requires formatting your CSV files to match the system's exact specifications and understanding the strict requirements for different data fields.
Admin Side: Before formatting your CSV file, it is essential to understand the different levels of field requirements:
-
Unique ID Fields: These fields are required and are absolutely crucial for identifying a record as a unique entity in the system before it is assigned an internal ID. They represent the bare minimum information needed to import a distinct record.
-
Recommended Fields: While not technically mandatory for a record to be created, these fields contain information that makes the record a genuinely useful entity within the system (e.g., a user's first and last names or the fine value on a violation). A record can exist without them, but its administrative utility will be severely limited.
-
Optional Fields: These fields are not required, and a record without them can still function normally. They contain supplemental information that can be filled in later or isn't essential for basic functionality (e.g., a vehicle's manufacturing year).
User Side: End-users do not interact with the database importer or its CSV formatting requirements.
Using this Feature
Administrators reference the tables below to map their external data columns to the corresponding OPS-COM internal names and data types.
UserProfile Table
| Column Name | Internal Name | Requirement | Type | Description |
| User Unique ID (UUID) | UserUUID | Unique ID | Standard | The primary identifier. If UUID is not supplied, email is used as the key identifier instead. Either this or the email is required. |
| Email Address | Unique ID | Standard | The secondary identifier. Either this or the UUID is required to import a record. | |
| Username | username | Recommended | Standard | The username of the user. |
| First Name | firstName | Recommended | Standard | The first name of the user. |
| Middle Name | middleName | Optional | Standard | The middle name of the user. |
| Last Name | lastName | Recommended | Standard | The last name of the user. |
| Password | password | Optional | Standard | The password of the user. |
| User Type | UserTypeID | Recommended | Foreign Key | Attaches to the UserTypes table. Values must exactly match the TypeName column (case, spelling, and spacing). Blank if no match is found. |
| Street Address | street | Optional | Standard | The street address of the user. |
| City | city | Optional | Standard | The city of the user. |
| Province/State | prov | Optional | Foreign Key | Attaches to the Provinces table. Values must exactly match the ProvName column (long names, not abbreviations like ON). |
| Postal Code | postal | Optional | Standard | The postal or ZIP code of the user. |
| Cellphone Number | phonecell | Optional | Standard | The cellphone number of the user. |
| Employee Number | employNo | Optional | Standard | The employee number of the user. |
| Student Number | studentNo | Optional | Standard | The student number of the user. |
| Secondary Phone | sPhone | Optional | Standard | The secondary phone number of the user. |
| Date of Birth | DOB | Optional | Standard | The date of birth of the user. |
| Preferred Name | preferredname | Optional | Standard | The preferred name of the user. |
| Public Comment | publicComment | Optional | Standard | Public comment for the user. Visible to the user. |
| Private Comment | privateComment | Optional | Standard | Private comment for the user. Not visible to the user. |
| Login Source | loginSource | Optional | Standard | The method by which the user logs into the system. Defaults to OPSCOM if not supplied. |
OffenseLocations Table
| Column Name | Internal Name | Requirement | Type | Description |
| Location Name | LocationName | Unique ID | Standard | The name of the location being imported. Required to import a record. |
| Writer Visible | WriterVisible | Optional | Standard | Indicates whether the writer of a violation ticket made in the location is visible to the user. |
| GIS Number | GisNo | Optional | Standard | Geographic location code used by certain clients for GIS maps integration. |
Vehicle Table
| Column Name | Internal Name | Requirement | Type | Description |
| Licence Plate | Plate | Unique ID | Standard | The license plate number of the vehicle. Required to import a record. |
| Vehicle Year | Year | Optional | Standard | The manufacturing year of the vehicle. |
| Active Vehicle | active | Optional | Standard | Indicates whether the vehicle is active. Defaults to active if not supplied. |
| Plate Type Name | PlateTypeID | Optional | Foreign Key | Attaches to the VehiclePlateType table. Must be an exact match to the TypeName column. |
| Province/State | ProvID | Optional | Foreign Key | Attaches to the Provinces table. Must be an exact match to the ProvName column (long names only). |
| Vehicle Make Name | MakeID | Optional | Foreign Key | Attaches to the VehicleMake table. Must be an exact match to the MakeName column. |
| Vehicle Type Name | TypeID | Optional | Foreign Key | Attaches to the VehicleType table. Must be an exact match to the TypeName column. |
| Vehicle Colour Name | ColourID | Optional | Foreign Key | Attaches to the VehicleColours table. Must be an exact match to the ColourName column. |
| VIN Number | vin | Optional | Standard | The Vehicle Identification Number (VIN). |
Permits Table
| Column Name | Internal Name | Requirement | Type | Description |
| Permit Number | PermitNo | Unique ID | Standard | First primary identifier. Both this and LotNameID must be provided to create a new permit. |
| Lot Name (Long) | LotNameID | Unique ID | Foreign Key | Second primary identifier. Attaches to the LotNames table. Must be an exact match to the long-form LotName column. |
| Visible | visible | Optional | Standard | Indicates whether the permit is visible or not. |
| Permit Status | status | Optional | Standard | The administrative status of the permit. |
| Permit State | StateID | Optional | Foreign Key | Attaches to the PermitState table. |
Violations Table
| Column Name | Internal Name | Requirement | Type | Description |
| Ticket Number | Ticket | Unique ID | Standard | The unique identifier for the violation. Required to import a record. |
| Licence Plate | VehicleID | Recommended | Foreign Key | Attaches to the Vehicle table. Must be an exact match to the Plate column. |
| Ticket Type Name | TicketType | Recommended | Foreign Key | Attaches to the TicketCategory table. Must be an exact match to the TicketTypeName column. |
| Fine Amount | Fine | Recommended | Standard | The amount of the fine associated with the ticket. |
| Towing Amount | Towing | Optional | Standard | The amount of towing charges associated with the ticket. |
| Tax Amount | taxAmount | Optional | Standard | The amount of tax associated with the ticket. |
| Issued Date | Issued | Recommended | Standard | The date the ticket was issued. |
| Due Date | Due | Recommended | Standard | The due date for payment of the ticket. |
| Ticket Writer | Writer | Optional | Standard | The administrator who wrote the ticket. |
| Violation Location Name | LocationID | Recommended | Foreign Key | Attaches to the OffenceLocations table. Must be an exact match to the LocationName column. |
Best Practices and Considerations
-
Ensure exact matches for Foreign Keys: For all Foreign Key type columns, the values in your CSV file must be an exact match (including capitalization, spelling, and spacing) to the corresponding Name column in the referenced OPS-COM table. Any mismatch will result in a blank or Null value in the imported record.
-
Prioritize core fields: Ensure all Unique ID fields are present and accurate, and Recommended fields are heavily populated for maximum utility of the imported records.
-
Pre-populate reference tables: Before importing data that relies on foreign keys, ensure the corresponding reference tables are already populated in OPS-COM with all necessary values. This prevents immediate Null values in your imported data.
-
Maintain data consistency: Maintain consistent formatting for dates, phone numbers, and other standard fields within your CSV to avoid syntax-related import errors.
-
Test with small batches: For large imports, always consider testing with a small batch of records first to verify that your column matching and data formatting are correct before importing the entire historical dataset.
Create or Refresh a Preview Space
The Preview Space feature allows administrators to generate a secure, isolated testing environment that mirrors their live production system data. Its primary purpose is to provide a safe sandbox for testing new features, staging system changes, and conducting training without impacting operational data or actual end-users. This article is intended for OPS-COM administrators responsible for managing system testing and training environments.
Setup and Configuration
Preview spaces are generated on demand directly from your live production environment.
Admin Side: Administrators require high-level system access to push data from the live database to a preview environment. No user-side configuration is required, as this is strictly an administrative testing tool.
Using this Feature
Administrators can use the following instructions to generate, access, and manage the active state of their preview database.
Creating or Refreshing a Preview Space
-
Hover over Tools and click Database to Preview in your live production system.
-
Select Backup Production Database to capture up-to-date information, or select a specific date from the drop-down menu to use an older historical backup.
-
Wait for the manual backup process to complete, if applicable.
-
Click the Refresh Preview Database button to push the data to the testing environment.
The database refresh process typically takes 1 to 2 minutes, but it can take up to 15 minutes depending on the total size of your organization's database. A notification message will display along the top of the screen to alert you when the refresh is officially complete.
Accessing the Preview Space
-
Open your web browser's address bar.
-
Insert
.previewimmediately after your organization's subdomain name and before the main OPS-COM domain (e.g.,[https://yourorganization.preview.OPS-COM.com](https://yourorganization.preview.OPS-COM.com)). -
Press Enter to navigate to the isolated sandbox environment.
Locking and Unlocking the Database
Administrators can lock the preview database to prevent other staff members from accidentally refreshing the system and overwriting active testing or development work.
-
Log in to your preview site.
-
Hover over Tools and click Reset Database.
-
Toggle the lock or unlock setting as needed.
-
Enter a justification in the provided reason field when prompted by the system.
Visual Cues and Status Indicators
Best Practices and Considerations
-
Understand email suppression rules: All email notifications are automatically captured and suppressed in the preview environment. This is a deliberate security measure to prevent accidental communications—such as test citations or training receipts—from reaching actual clients or external recipients.
-
Plan for automatic deletion: Preview sites are automatically deleted after 7 days of no login activity. If your team requires a preview site for an extended training period or a long-term staging project, you must contact OPS-COM support staff so a custom expiry date can be set.
-
Utilize daily data backups: Production data is backed up daily at 2 AM EST and is available to push to the testing environment at any time. If you perform a refresh of your preview site without initiating a brand new manual backup, the system will automatically pull the data captured from the night before.
Resolve Duplicate Options
The Resolve Duplicates feature allows administrators to identify and merge duplicate records by email, student number, staff number, and vehicle plate. Its primary purpose is to maintain data accuracy, prevent operational errors, and ensure that enforcement and permit management processes rely on clean, unique data. This article is intended for OPS-COM administrators responsible for system data maintenance and focuses specifically on resolving vehicle duplicates.
Setup and Configuration
This feature is a core administrative data maintenance tool and requires no specialized initial setup.
Admin Side: Administrators must have the appropriate system permissions enabled to access the data maintenance tools and execute merges.
User Side: This feature is strictly a backend administrative tool and is not accessible to end-users on the portal.
Using this Feature
Administrators can use the following instructions to generate a list of duplicate vehicles, select the appropriate retention data, and merge the records.
Resolving Duplicates By Vehicle
-
Hover over Tools and select Resolve Duplicates, then click By Vehicle.
-
Select your desired duplicate identification option to generate a list of potential duplicates.
-
Review the generated list carefully, paying close attention to vehicle descriptions and other details to confirm they are actual duplicates.
-
Click the Merge button next to the specific pair of duplicate records you wish to consolidate.
-
Select which specific data fields you wish to retain from the duplicate records in the merge function window.
-
Finalize the merge to permanently combine the records.
Available Actions and Buttons
-
Strict Duplicate: Select this option to generate a list of vehicles where all three primary unique identifiers (Plate, State/Province, and Plate Type) are identical. This is used for finding exact, unambiguous duplicates.
-
Include Different Plate Types: Select this option to generate a list of vehicles where the Plate and State/Province are identical, but the Plate Type may differ.
-
Merge: Click this button next to a pair of duplicate entries to open the data retention window and begin the consolidation process.
The Include Different Plate Types option is highly useful for identifying input errors. For example, if a vehicle was entered once with an unspecified plate type and a second time as a passenger plate, this search criteria will flag them as potential duplicates so you can compare the make, model, and color to confirm.
Best Practices and Considerations
-
Understand core vehicle identification: In OPS-COM, vehicles are uniquely identified by three key pieces of information: License Plate, Province / State, and Plate Type. All three details are essential for a vehicle to be considered unique within the system, as the exact same plate number could theoretically exist as both a passenger and commercial plate in the same province.
-
Perform careful reviews before merging: Always thoroughly review potential duplicates before finalizing a merge, as merging incorrect records can lead to permanent data loss or inaccuracies. Ensure you are selecting the most accurate and complete data fields to retain during the final step.
-
Establish regular data maintenance routines: Periodically run the Resolve Duplicates report to maintain a clean and accurate vehicle database. This is especially important after periods of high user registration or manual data entry. Duplicate vehicles can cause significant confusion, particularly when multiple drivers are associated with the same vehicle.
-
Encourage proactive data entry: The more information included when adding a vehicle to the system, the better the system can recognize potential duplicates. It is highly recommended to always include the vehicle's color, make, model, and year to clearly identify specific vehicles and reduce errors.
-
Investigate common duplicate causes: Be aware of common scenarios that lead to duplicates, such as manual data entry typos, slight variations in state entry, or orphaned violations. Identifying these root causes can help you improve user training and refine data entry procedures to minimize future occurrences.
History Search
The History Search feature allows administrators to quickly locate and review historical system activities and events. Its primary purpose is to provide a comprehensive log of system interactions, making it an invaluable tool for auditing, troubleshooting, and investigating specific actions related to users, vehicles, or violations. This article is intended for OPS-COM administrators.
Setup and Configuration
This feature is a core administrative auditing tool and does not require specific module configuration to begin logging data.
Admin Side: Administrators must have the appropriate system role permissions enabled to access the Tools menu and view the system history logs.
User Side: This feature is strictly a backend administrative tool and is not accessible to end-users on the portal.
Using this Feature
Administrators can use the following instructions to navigate to the search page and locate specific historical records.
Performing a History Search
-
Hover over Tools and click History Search to open the History Dump page.
-
Enter the desired search criteria into one or more of the available fields.
-
Click the Submit button.
-
Review the generated list of all system history records that match your entered search criteria.
Available Search Criteria
-
Student/Employee Number: Enter the specific identification number associated with a student or employee to pull all historical actions related to that account.
-
Violation Ticket: Enter the specific citation number to track the lifecycle of a ticket.
-
History Description: Enter keywords or phrases from the description of the historical event. This field allows for broad searches based on the recorded action rather than a specific ID.
You can perform a search using a single identifier (such as just a ticket number) or a combination of multiple fields to carefully narrow down your results on the History Dump page.
Available Actions and Buttons
-
Submit: Click this button to execute the search query and refresh the page with the relevant historical data.
Best Practices and Considerations
-
Combine criteria for precision: To achieve more accurate and manageable results, especially in systems with extensive history logs, combine search criteria. For example, you can enter a specific Student/Employee Number along with a targeted History Description keyword to find exactly when a user's address was changed.
-
Balance broad versus specific searches: Start with specific criteria if you know exactly what you are looking for. If you are unsure of the exact record, use broader terms in the History Description field and then refine your search as you gather more context.
-
Utilize for auditing and troubleshooting: This tool is excellent for auditing user actions, tracking changes, and troubleshooting issues. It allows administrators to review the exact sequence of events, which is critical for resolving disputes or tracking down data entry errors.
-
Integrate into daily operations: Familiarize yourself with this feature for daily operations. It can quickly answer questions about past system interactions without needing to navigate through multiple individual user profiles or vehicle records.
Purge Old - Explained
The Purge Old Data feature allows administrators to remove inactive historical records that have not had any activity associated with them for more than seven years. Its primary purpose is to maintain database efficiency, improve system performance, and ensure data remains relevant by clearing out old, unused information. This article is intended for OPS-COM administrators responsible for system maintenance and data retention.
Setup and Configuration
This feature is a core administrative data maintenance tool and requires no specialized initial setup to enable.
Admin Side: Administrators must have the appropriate system permissions enabled to access the data maintenance tools and execute a system purge.
User Side: This feature is strictly a backend administrative tool and is not accessible to end-users on the portal.
Using this Feature
Administrators can use the following instructions to generate a list of inactive records and execute the system purge.
Executing a Data Purge
-
Hover over Tools and click Purge Old Data to initiate the identification process.
-
Wait for the progress bar to complete as the system compiles a list of any user activity and associated record updates that have occurred within the last seven years.
-
Review the system prompt indicating the number of inactive records identified for potential purging.
-
Click the Purge these records button to complete the process and execute the deletion of any data not found on the active list.
Any small update or activity on a record will automatically restart its seven-year clock. This business rule ensures that the record is excluded from purging and preserved for another seven years from that last activity date.
Purged Record Types
The following record types will be permanently purged if they have had no activity in the last seven years:
-
User profiles
-
Vehicles
-
Violations
-
Permits
-
Appeals
-
Temp Permits
-
Payments
-
Lockers
-
Access Cards
-
Gate Events
-
Refunds
-
Waitlist Records
-
User History
Retained Record Types
The following record types will NOT be purged, regardless of their last updated date, ensuring the retention of critical long-term information:
-
Incident Users
-
Contact History
Best Practices and Considerations
-
Review data retention policies: Administrators should ensure this purge process aligns with their organization's data retention policies and legal compliance requirements. Because purged data is permanently deleted, it is critical to confirm that your organization does not legally require records older than seven years to be held on file.
-
Schedule appropriately: Consider running this purge during off-peak hours to minimize any potential impact on system performance. Although the process is designed to be efficient, scanning and deleting large volumes of historical data can temporarily draw system resources.
-
Acknowledge historical context: Be aware that while purged records are removed, essential incident and contact history data remains intact for long-term reference. This ensures that major historical interactions are preserved even if the associated user profile or vehicle has been cleared out.
Purging Incidents
The Incident Purging feature allows administrators to permanently remove outdated incident records from the system. Its primary purpose is to maintain data relevance, comply with organizational data retention policies, and optimize overall database performance. This article is intended for OPS-COM administrators responsible for system maintenance and data lifecycle management.
Setup and Configuration
This feature requires specific administrative permissions to access the deletion tools.
Admin Side: Administrators must have the Delete Incidents permission enabled within their specific user role to purge records. Consult your system administrator or review the Manage Roles and Permissions page for detailed instructions on modifying access levels.
User Side: This feature is strictly a backend administrative tool and is not accessible to end-users on the portal.
Using this Feature
Administrators can use the following instructions to purge outdated incidents either individually through a standard search or in bulk using the dedicated purging utility.
Purging incidents is a permanent and irreversible action. Once an incident is successfully purged from the system, its data cannot be recovered. Exercise extreme caution and verify your selections before confirming any deletion.
Purging Individual Incidents
-
Search for the specific incident you wish to purge using the standard incident search functionality.
-
Review the incident details on the screen and locate the Delete Incident button.
-
Click the Delete Incident button to initiate the removal.
-
Follow the on-screen prompts and confirmation messages to finalize the deletion.
The Delete Incident button will only be active and clickable if the incident record is strictly older than 7 years. If the incident is less than 7 years old, the button will display as Delete Not Available and remain disabled to enforce retention policies.
Purging Incidents in Bulk
-
Hover over Tools and click Purge Incidents to open the search screen.
-
Enter your search criteria into the available fields, such as specific date ranges or incident types.
-
Review the generated list, which is limited to displaying the oldest 300 records that match your criteria.
-
Enable the Delete checkbox next to each specific incident you wish to purge.
-
Click the Purge Records button.
-
Click the Delete button within the confirmation prompt to finalize the action.
When entering a value into the Number of Instances field on the bulk search screen, the system treats it as a "greater than or equal to" variable. For example, supplying the number 1 may still display incidents that have multiple instances attached to them.
Available Actions and Buttons
-
Delete Incident: Click this button on an individual incident page to permanently remove that specific record from the database.
-
Purge Records: Click this button during a bulk search to simultaneously delete all selected records.
Best Practices and Considerations
-
Conduct pre-purge reviews: It is highly recommended to perform a thorough review of all search results before executing a bulk purge. Because bulk deletions process multiple records at once, carefully verifying your selections ensures that no critical data is inadvertently removed.
-
Adhere to the 7-year retention rule: Administrators must be aware of the system's built-in 7-year data retention policy. Incidents cannot be purged using the individual button method if they are newer than 7 years, and the bulk purge tool prioritizes older records to prevent premature data loss.
-
Restrict deletion permissions: Carefully manage the Delete Incidents permission. Only grant this access level to trusted, senior administrators who fully understand the irreversible nature of database purging.
-
Establish a comprehensive audit trail: Ensure your organization has an appropriate backup strategy if long-term historical access to incident data is required for legal compliance. While the active record is cleared from the database to optimize performance, you may still need offline archives for future reference.
Handheld Devices and Commons
The Handheld Devices and Commons section allows OPS-COM administrators to manage and configure the mobile devices used for field enforcement and data collection. Its primary purpose is to centralize device registration, facilitate message broadcasting to field personnel, and manage device-specific settings to ensure accurate and seamless data synchronization.
Setup and Configuration
This feature is a core administrative tool for managing your organization's physical enforcement hardware.
Admin Side: Administrators must have the appropriate system role permissions enabled to access the device management tools. Furthermore, field devices must have the OPS-COM Android application installed and maintain an active network connection to receive configuration updates and pushed messages from the system.
Using this Feature
Administrators can use the device management interface to oversee their fleet of enforcement handhelds, push updates, and register new hardware.
Managing Devices
Available Actions and Buttons
-
Register Device: Allows administrators to securely add a new handheld unit to the operational system.
-
Push Message: Enables administrators to send direct communications, alerts, or system updates to active field personnel.
-
Update Settings: Allows for the modification of device-specific configurations to ensure seamless operation and data accuracy.
This page serves as a high-level overview of the Handheld Devices module. For detailed, step-by-step instructions on configuring specific handheld models, installing the application, or troubleshooting synchronization issues, please refer to the Handhelds Devices Settings (Handheld Commons) wiki article.
Best Practices and Considerations
-
Maintain active device lists: Administrators should routinely review the list of registered handhelds and deactivate devices that are lost, broken, or no longer in use. Keeping a clean device list ensures system security and prevents unauthorized hardware from syncing with your live database.
-
Verify network connectivity: Remind field personnel that devices must be connected to a reliable Wi-Fi or cellular data network to receive pushed messages and settings updates. If a device is offline, any settings updated in the admin portal will not take effect until the device reconnects and syncs.
Managing Recurring and Onetime System Tasks
The Scheduled Tasks feature utilizes both recurring and onetime system tasks to automate various backend processes, such as data synchronization, report generation, and system clean-up. Its primary purpose is to allow administrators to monitor, enable, and disable these critical automated functions, ensuring the efficient operation of the environment. This article is intended for OPS-COM administrators responsible for backend system maintenance.
Setup and Configuration
This feature is a core administrative tool and does not require complex initial configuration to access.
Admin Side: Administrators must have the appropriate system role permissions enabled to access the Tools menu and view system task logs.
Using this Feature
Administrators can use the following instructions to access task logs, monitor execution times, and toggle automated tasks on or off.
Accessing System Tasks
-
Hover over Tools and click View System Task Logs.
-
Review the Scheduled Tasks page, which is divided into two main sections: Recurring tasks and Onetime tasks.
Key Information Displayed
For each task listed on the page, the system provides several key metrics to help administrators monitor backend performance:
-
Task Name: The name of the automated system task.
-
Last Run: The timestamp indicating the last time the task was executed.
-
Next Run: The scheduled timestamp for the next planned execution of the task.
-
Average Duration: The average amount of time it takes for the task to complete its execution.
-
Enabled Status: Indicates whether the task is currently active and configured to run automatically.
Available Actions and Buttons
-
Enabled Checkbox: Enable the Enabled checkbox next to a specific task to allow it to run according to its schedule, or disable the checkbox to prevent it from running.
-
Logs: Click this button next to any task to view a pop-up window containing detailed information and historical logs about the task's past executions, including success/failure statuses and specific output details.
Please be aware that there are often other module-specific settings that must be configured correctly before enabling a related system task. Ensure you have fully set up the feature before toggling its automated task to active.
Best Practices and Considerations
-
Monitor task logs regularly: Administrators should periodically review the logs for critical system tasks to ensure they are completing without errors. Proactive monitoring helps identify and resolve potential backend data issues before they impact daily operations.
-
Understand task impact before enabling: Always familiarize yourself with the purpose and function of each system task before enabling or disabling it. These tasks can significantly affect data integrity, system performance, or other automated processes.
-
Schedule maintenance appropriately: Coordinate the scheduling of heavy onetime tasks with periods of low system activity. Running resource-intensive automated processes during off-peak hours minimizes any potential impact on the end-user experience.