System Configuration Guide to System Settings The System Settings feature provides administrators with comprehensive control over the core functionalities and behaviors of the application. Its primary purpose is to allow for the centralized configuration and fine-tuning of various components, including security protocols, parking modules, and payment processing, ensuring the system operates according to organizational needs. This article is intended for OPS-COM administrators responsible for managing backend system configurations. Setup and Configuration This feature is a core administrative tool that dictates global system behavior. Admin Side: Administrators must have the Manage System Configuration permission enabled within their user role to view and edit the system settings. Using this Feature Administrators can use the following instructions to navigate the system settings and configure global application parameters. Accessing System Settings Hover over System Configuration and click System Settings to access the centralized configuration area. Explore the available configuration menus to locate the specific module or parameter you wish to adjust. Hover your cursor over any specific menu item label to view a tooltip explaining exactly what that setting controls. Modify the required settings to align with your organizational workflows. Visual Cues and Status Indicators Blue Text: Settings displayed in a blue font are read-only to standard administrators. These represent core system parameters that only a Tomahawk User can enable or disable. Tooltips: Hovering over setting names will display a helpful tooltip detailing the function and impact of that specific toggle or field. If your organization requires a change to a setting displayed in blue text, please communicate your needs clearly and contact support@ops-com.com  for assistance with the configuration. Best Practices and Considerations Review all settings: Regularly review all components to ensure configurations align with your organization's current policies and operational needs. System settings are granular and cover many distinct aspects of the application. Prioritize security settings: Prioritize the configuration of the security component settings to maintain a robust security posture for your admin accounts. This includes strictly defining password expiry limits, strength requirements, and admin lockouts. Verify email configuration: Ensure that all relevant email addresses are correctly set up to guarantee timely system communications and alerts. Key fields to verify include the Default Notification Email, From Email, Appeal Notification Email, and Automated Notification Email. Maintain time zone accuracy: Correctly setting your Time zone and Time offset is critical. These configurations ensure the completely accurate timestamping of all system events, purchased permits, and issued violations. Understand the impact of toggles: Understand the full impact of enabling or disabling a module or specific feature before making changes. Be mindful that many settings act as simple on/off switches that can immediately alter system behavior and user visibility. Foster team collaboration: Collaborate with your internal teams, such as IT, finance, and enforcement, to ensure changes meet everyone's operational requirements. Test significant changes: Consider testing significant changes in a preview environment before applying them to your live production system. This is highly recommended for settings that heavily impact user-side visibility or core workflows. For detailed setup instructions, refer to the  Create or Refresh a Preview Space page. Configuring SAML SSO with OPSCOM What is Single Sign-On (SSO) Single Sign-On (SSO) simplifies user access to OPSCOM by allowing them to authenticate using their existing, managed corporate accounts. This eliminates the need for separate OPSCOM usernames and passwords, enhancing convenience and security. This article details the setup and configuration of SAML-based SSO with OPSCOM, explaining the necessary fields, metadata exchange, and user synchronization.  For more general information about SSO and OPSCOM refer to this wiki article . Prerequisites and Considerations Implementing SSO with OPSCOM, specifically using SAML (Security Assertion Markup Language), requires coordination between your organization's Identity Provider (IdP) and OPSCOM as the Service Provider (SP). Paid Feature : SSO is a paid feature. You must have the setup fee and recurring fees negotiated before proceeding. Contact your Sales Representative or email support@ops-com.com to initiate this. Login Sources : You must first follow the instructions to set up Login Sources within OPSCOM, as SSO will be configured as a specific login source. User Management Strategy : Consider the following: Will you have different Login Sources (e.g., Students/Staff use SSO, but Public Users do not)? Will login sources vary by user type? How do you want to initially get your users into OPSCOM (e.g., pre-import vs. on-the-fly creation)? Do you want users to be created automatically upon their first SSO login? Do you want to keep user information synchronized with your Identity Provider regularly, or will it be a one-time import? What user profile data/fields do you want synchronized between your SSO system and OPSCOM? Can you take advantage of the UserPush APIs for proactive user synchronization? Your OPSCOM Client Success team will be happy to discuss these options to ensure a smooth and successful setup. Once the prerequisites are addressed, the SAML setup involves configuring fields for both OPSCOM (as the Service Provider) and your external SAML system (as the Identity Provider). Configuring SAML Setup Hover over System Configuration, Users, and click Login Sources. Click the pencil icon to edit your login source you created already as mentioned above. You should already have configured the login source to the point of the Unique ID field. The settings below must be filled out correctly and saved before you will see the Metadata tab to continue. When OPSCOM generates your SP metadata, it is available as a live URL — not just a downloadable file. The metadata URL follows this pattern: https://[your-domain]/auth/saml2/[ENTITY_ID]/metadata We strongly recommend providing your Identity Provider with this URL rather than a downloaded XML file. When an IdP is configured to pull from a live URL, it will automatically fetch fresh metadata and the integration stays current. If you upload a static XML file to your IdP instead, be aware that the metadata contains a validUntil timestamp (calculated from the cacheDuration of 7 days from the time it was fetched). An IdP that strictly enforces this value may reject the metadata after that window. In practice, most enterprise IdPs — including Azure AD — do not enforce validUntil on uploaded SP metadata, but it is still better practice to use the live URL wherever possible. Azure AD note: When configuring the Enterprise Application in Azure, look for the option to enter a Federation Metadata URL rather than uploading a file. This is found in the Basic SAML Configuration section. Service Provider Fields (Configured in OPSCOM) These fields define how OPSCOM will interact with your Identity Provider. Unique ID :  Required - This is a crucial part of the XML communication between OPSCOM and your SAML system. It is supplied by your SAML system and is the value OPSCOM uses to match against its internal UniqueID field to identify a user. Entity ID for Service Provider :  Required - This value defines the unique SAML integration path within the URL in the metadata. If your OPSCOM system has more than one SAML integration, each Entity ID needs to be unique. The value you supply will appear in the integration path like this: https://client.OPSCOM.com/auth/saml2/ENTITY_ID_FIELD/acs .  Only add the ENTITY_ID_FIELD not the whole URL.    SP x509 Certificate: (Optional) This is the certificate OPSCOM will use to sign or decrypt SAML messages. It is generated within your OPSCOM or IdP setup — it is not the same as the IdP's certificate. You only need to configure this field if you are enabling signed logout requests, signed logout responses, or encrypted assertions. All three of those features are disabled by default. Private Key: (Optional)  Required only if the SP certificate above is in use. Leave blank for standard configurations. Identity Provider Fields (Configured in OPSCOM, Values from Your SAML System): These fields capture information from your external SAML system (Identity Provider). You will find these values within your SAML system's metadata (e.g., often displayed under  Federation → Show Metadata on your SAML installation page). You will input values such as the Identity Provider's Entity ID , Single Sign-On URL (SSO URL) , and x509 Certificate (which is often different from the one provided for the Service Provider). ⚠️ Important — Certificate Mismatch: The IdP x509 Certificate field must contain the certificate issued by your Identity Provider — for example, the certificate embedded in Azure's Federation Metadata XML. Do not copy the SP certificate into this field. Entering the wrong certificate here will cause SAML assertion validation to fail silently, and users will be unable to log in. If in doubt, download your IdP's Federation Metadata XML and extract the certificate from within it. Once these settings have been completed and saved in OPSCOM, you will gain access to additional tabs:  MetaData , Synchronization , and Translations .   Additional Settings Reference When you open your Login Source configuration, you will see several additional fields below the core SP and IdP sections. The defaults are appropriate for most integrations, but the following are worth understanding: Setting Default What It Does Requested Auth Context false When set to false , OPSCOM does not specify an authentication method in its request to the IdP — the IdP decides. Set to true to require password-based authentication ( PasswordProtectedTransport ). Leave as false for most Azure AD integrations. Require Name ID Policy Enabled Includes a NameIDPolicy element in the SAML request, specifying the Name ID Format. Disable this if your IdP is Microsoft ADFS — ADFS frequently rejects the NameIDPolicy element and returns an InvalidNameIDPolicy error. Azure AD (Entra ID) handles it correctly and this should remain enabled. Require Encrypted Assertions Disabled Requires the IdP to encrypt SAML assertions. Only enable if your IdP supports it and your SP certificate and private key are configured. Not required for standard Azure AD integrations. Sign Logout Requests / Responses Disabled Requires the SP certificate and private key to be configured. Not required for standard Azure AD integrations. Using this Feature Metadata Tab The Metadata tab in OPSCOM provides the XML code that you will need to provide to your Service Provider (OPSCOM, in the context of SAML communication from your IdP's perspective). This XML contains all the necessary information for your Identity Provider to communicate correctly with OPSCOM. Sample XML File Sample XML File Explanation : When your external system (e.g., a SimpleSAMLPhp service set up as the identity provider) sends a response back to OPSCOM, it includes an saml:AttributeStatement tag containing several attributes. These attributes are required for OPSCOM to match to a user within its system. The most important field in this attribute section is the value used as the permanently unique identifier for a user. For example, if the XML response shows [uid] => Array ( [0] => 6ddf4027-3397-4e45-8628-0189f60fe91e ) , then uid should be entered as the Unique ID Field in your Identity Provider Fields configuration within OPSCOM. If the unique ID is something else, such as SAMaccountName , then that should be used instead. ... DEV-2K8  - DEBUG: Saml2 Incoming User Array ( [uid] => Array ( [0] => 6ddf4027-3397-4e45-8628-0189f60fe91e ) [full name] => Array ( [0] => Sarah Knowles ) [email] => Array ( [0] => sknowles@tomahawk.ca ) ) [] < samlp:Response   xmlns:samlp = "urn:oasis:names:tc:SAML:2.0:protocol"   xmlns:saml = "urn:oasis:names:tc:SAML:2.0:assertion"   ID = "_aa1963115aa6490e728c7376f4c8849813bbb..." > ... < saml:Assertion   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"   xmlns:xs = "http://www.w3.org/2001/XMLSchema"   ID = "_9efd79bf6425983ee9176f3d33a99d1a9176180..." > ... < saml:Subject > < saml:NameID   SPNameQualifier = "MinionOpsComStaff"   Format = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" >_7a426e0be71f14c1f349db00d7d543b6f7dcb52baa < saml:SubjectConfirmation   Method = "urn:oasis:names:tc:SAML:2.0:cm:bearer" > < saml:SubjectConfirmationData   NotOnOrAfter = "2021-08-24T16:00:41Z"   Recipient = "https://minion-3.dev.parkadmin.com/auth/saml2/MinionOpsComStaff/acs"   InResponseTo = "ONELOGIN_bb8a09203c888cf59af4c621a71cfa8f7559c016" /> < saml:Conditions   NotBefore = "2021-08-24T15:55:11Z"   NotOnOrAfter = "2021-08-24T16:00:41Z" > < saml:AudienceRestriction > < saml:Audience >MinionOpsComStaff < saml:AuthnStatement   AuthnInstant = "2021-08-24T15:34:46Z"   SessionNotOnOrAfter = "2021-08-24T23:34:46Z"   SessionIndex = "_a7a68666092117d24aab8adecf1b0830622855b85..." > < saml:AuthnContext > < saml:AuthnContextClassRef >urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport     < saml:AttributeStatement > < saml:Attribute   Name = "uid"   NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:basic" > < saml:AttributeValue   xsi:type = "xs:string" >6ddf4027-3397-4e45-8628-0189f60fe91e < saml:Attribute   Name = "full name"   NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:basic" > < saml:AttributeValue   xsi:type = "xs:string" >Sarah Knowles < saml:Attribute   Name = "email"   NameFormat = "urn:oasis:names:tc:SAML:2.0:attrname-format:basic" > < saml:AttributeValue   xsi:type = "xs:string" >sknowles@tomahawk.ca     ⚠️ Do not rename your Login Source after users have been associated to it. The Login Source value is stored against every user record created via SSO. If you change it, those users will no longer be matched to this login source on their next login attempt, effectively locking them out. If a rename is ever necessary, contact OPSCOM Support to arrange a coordinated update of all affected user records. Synchronization Tab The Synchronization tab allows you to configure how user information is managed between your SSO system and OPSCOM. Auto Create/Update User : To begin, ensure you enable the Auto Create/Update User checkbox. This feature allows OPSCOM to automatically create new user profiles when they first log in via SAML, if they don't already exist in OPSCOM. It also enables the system to update existing user information. User Attribute Mapping : On this tab, you will map the user attributes from your SSO system (your Identity Provider) to the corresponding fields in OPSCOM. For example, your SSO system might send "full name" and "email" attributes, which you would map to OPSCOM's firstName , lastName , and email fields. Any field that is mapped and has a value from your SSO side should get updated to the value from SAML. After you have provided the information in each field, click  Save Changes . Your users will then begin to be created or updated automatically upon their SSO login attempts. If any of the supplied fields are incorrect or don't match, the corresponding information will be blank in OPSCOM when the user logs in, or it will remain unchanged if the user already existed. What to enter in the field mapping boxes: Each field mapping box accepts the attribute name exactly as your Identity Provider sends it in the SAML assertion. These names vary between IdP systems. The sample values shown (such as full name , email , uid ) are from a SimpleSAMLphp test installation and will be different for other identity providers. For Azure AD (Microsoft Entra ID) , the attribute names depend on how the claims were configured in the Enterprise Application. Azure uses two formats: Short-name format (if you created custom claims): e.g., first_name , last_name , emailaddress Full URI format (Azure defaults): e.g., http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname To confirm exactly what your Azure AD tenant is sending, use the Test button on the Single sign-on page of your Azure Enterprise Application. The test result displays every claim name and value as it will arrive at OPSCOM. ⚠️ Azure AD does not send a combined "full name" attribute by default. If you map the First Name field to a full name or displayName attribute, the user's entire display name (e.g., "Sarah Knowles") will be stuffed into the first name field. Map First Name and Last Name to separate attributes (givenname / surname, or first_name / last_name if configured as custom claims in Azure). The exact sample values from our test system may differ from your actual SAML system attributes. Translations Tab The Translations tab allows you to customize the text displayed on your login button from the user side. You can create as many different translations as are available in your system (e.g., English and French). This ensures that the SSO login experience is localized for your users. Error Handling: CommonPproblems and Their Causes User cannot log in / "user not found" — The Unique ID Field in OPSCOM does not match the attribute name being sent by the IdP, or the user has not been assigned to the application in the IdP. Assertion validation failure — The IdP x509 Certificate field contains the wrong certificate (often the SP cert copied in by mistake). InvalidNameIDPolicy error — Disable the "Require Name ID Policy" toggle (common with ADFS IdPs). Incorrect user data on auto-created accounts — A field mapping value doesn't match the attribute name the IdP is actually sending. Use your IdP's test/debug tool to see the exact claim names in the assertion. Login source mismatch — The Login Source value was changed after users were created. Contact OPSCOM Support. OPSCOM's SSO debug log (when enabled) will display the full incoming user array, which makes attribute name mismatches straightforward to identify. Best Practices & Considerations Coordinate with IT/SAML Administrator : Successful SSO implementation requires close collaboration with your organization's IT department or the administrator of your SAML Identity Provider. They will provide the necessary metadata and attribute names. Unique User Identifiers : Ensure the Unique Identifier chosen for matching users is truly unique and persistent within your SSO system. Incorrect or changing identifiers will lead to duplicate accounts or login failures. Attribute Mapping Accuracy : Carefully map all desired user attributes from your Identity Provider to OPSCOM. Inaccurate mapping will result in missing or incorrect user data. Test Thoroughly : After initial configuration, conduct thorough testing with various user types and scenarios to ensure seamless login, proper user creation/updates, and correct data synchronization. User Experience : Clearly communicate the new SSO login process to your users. Provide instructions on how to access OPSCOM via SSO and address any potential questions. Error Handling : Be prepared to troubleshoot potential issues. Common problems include incorrect Entity IDs, expired certificates, or mismatched attribute names. The SSO system logs can be invaluable for diagnosing such issues. Use the Metadata URL, not a downloaded file: When providing your SP metadata to an Identity Provider, share the live metadata URL from the Metadata tab rather than a downloaded XML file. This avoids the need to re-upload metadata when the validUntil timestamp rolls forward, and ensures the IdP always has current configuration data. Keep your SP and IdP certificates straight: A very common configuration error is entering the SP certificate in the IdP certificate field, or vice versa. The SP certificate comes from OPSCOM (or is generated during your Azure Enterprise Application setup). The IdP certificate comes from your Identity Provider's metadata. They are different certificates issued to different entities — treat them as such. Troubleshooting - Email Server Communication Errors This article outlines the process for identifying and resolving email server communication errors within the system. Its primary purpose is to help administrators fix incorrect or missing "From" and "Reply-to" email addresses so that automated system communications, such as password reset confirmations, are dispatched successfully. This guide is intended for OPS-COM administrators responsible for system configuration and troubleshooting. Setup and Configuration Resolving communication errors requires access to the global system settings. Admin Side: Administrators must have the appropriate system role permissions enabled to access the configuration menus and modify global email parameters. User Side: End-users cannot configure these settings. However, users typically surface these errors when attempting to trigger automated emails through portal actions, such as submitting a password reset request. Resolving the Error Administrators can use the following instructions to identify the root cause of the communication failure and apply the necessary email configurations to resolve it. Identifying a Communication Error When a user attempts an action that triggers an automated email (such as using the forgot password form), the system relies on predefined sender addresses. If these addresses are missing, the system will fail to send the message, and the user will see a popup stating that the system could not communicate with the email server. This error explicitly indicates that the system lacks a defined "From" or "Reply-to" address. Fixing Communication Errors Hover over System Configuration and click System Settings . Navigate to the General System Settings tab. Locate the Reply-to Admin Email Address field. Enter a valid, active email address into this field to serve as the system's sender address for automated communications. Click Save to apply the configuration changes. Re-attempt the user action that previously triggered the error (e.g., submitting the forgot password form) to verify the issue is resolved. Communication errors are almost always symptomatic of missing or incorrectly configured email parameters. If a user reports an email delivery failure or a communication error popup, verifying your global email settings should always be your first troubleshooting step. Best Practices and Considerations Maintain crucial email fields: The Reply-to Admin Email Address and other sender settings found within the system settings are critical for all automated communications. Ensure these fields are always populated with valid, actively monitored email addresses to prevent widespread delivery failures. Monitor system notifications: Regularly check the inbox of the email address configured as the Default Notification Email. Proactively monitoring this inbox helps administrators catch any internal system alerts regarding failed communications or server errors before end-users report them. Escalate persistent issues: If the issue is still not resolved after configuring these fields, please contact support@ops-com.com  for further assistance. When reaching out to support, be sure to provide specific details about the error message and the troubleshooting steps you have already completed. Alarms System Settings The Alarms System Settings feature allows administrators to configure and manage automated system alerts. Its primary purpose is to notify administrative and field enforcement staff of critical information regarding specific users, vehicles, or general events, thereby improving operational awareness and security. This article is intended for OPS-COM administrators responsible for backend configuration and enforcement operations. Setup and Configuration This feature is a core administrative tool used to define the active alerts that trigger within the system and on field enforcement devices. Admin Side: Administrators must have the appropriate system role permissions enabled to access and configure these settings. Hover over System Configuration and click Alarms System Settings . Review the active alarm categories and select the specific type you wish to configure or manage. Save any modifications to ensure they immediately propagate to the database and sync with active handheld devices. Using this Feature Administrators can use this feature to categorize and manage three distinct types of system alarms. Available Alarm Types People : Configure alarms that are tied directly to user profiles. This is commonly used to flag banned individuals, VIPs, or users with a history of severe parking infractions or unpaid violations. Plate/Vehicle : Configure alarms that are tied directly to specific license plates or registered vehicles. This ensures that field enforcement officers are immediately alerted if they scan a scofflaw, a stolen vehicle, or a plate associated with a suspended permit. Generic : Configure general alarms for broader system use that do not strictly tie to a single user profile or specific vehicle record. Alarms configured in the backend sync directly to the handheld units used by enforcement staff. When an officer searches a flagged plate or user profile, the Android device will prominently display the alert on the screen so the officer can take immediate action. Best Practices and Considerations Standardize alarm descriptions: Ensure that all configured alarms include clear, concise instructions for responding staff. Field officers need to know exactly what action to take when an alarm triggers (e.g., "Do not approach, call dispatch immediately" versus "Issue a standard warning"). Prevent alert fatigue: Regularly review active alarms and remove those that are no longer applicable. Keeping hotlists and active alarm triggers clean ensures that enforcement officers take alerts seriously when they do appear, rather than habitually dismissing them. Restrict configuration access: Organizations should strictly limit which administrators have the permission to create or modify system alarms. Tightly controlling this backend access prevents the system from becoming cluttered with unnecessary, duplicate, or poorly defined alerts. Defining User Profile Settings The User Profile Settings feature enables administrators to customize the specific information collected from users on their profile forms. Its primary purpose is to allow organizations to tailor the registration experience by controlling the visibility and mandatory status of data fields, ensuring that all necessary information is captured efficiently. This article is intended for OPS-COM administrators responsible for system configuration and user management. Setup and Configuration This feature is a core administrative tool used to dictate the fields presented to users during registration and profile updates. Admin Side: Administrators must have the appropriate system role permissions enabled to access the global system settings menu and modify user profile requirements. User Side: The configurations applied here directly dictate the fields end-users see and must complete when creating or updating their portal accounts. Using this Feature Administrators can use the following instructions to navigate to the settings menu and manage the visibility of various user profile fields. Configuring Field States Hover over System Configuration and click System Settings . Click User Profile on the Manage System Settings screen. Select the desired display state for each available profile item from the provided list. Available Field States The state selected for each field is highlighted in black, with a checkmark indicating the active selection. Items can be set to one of three states: Hidden: The field is not visible on the user-side profile form. Visible: The field is seen on the user-side form, but entering information is optional. Required: The field is seen on the user-side form and is mandatory. Required fields are indicated by a red asterisk. The system will not allow the user to save their profile if any required information is missing. Customizing Profile Sections The settings page allows you to customize several specific categories of user information: User Name: A user name is an essential unique identifier for system access. While a bare minimum typically includes a username, first name, and last name, any of these items can be toggled based on your needs. Address Information: This section is critical if your organization plans to mail physical permits or other correspondence to end-users. Phone Information: Allows for the collection of various personal and primary phone numbers. License Information: This field specifically refers to a driver's license number, not a vehicle license plate. You may opt to record this information if your organization is connected with local law enforcement. Student Information: Controls fields relevant to student identification, such as student numbers and maximum/minimum digit limits. Employee Information: Controls fields relevant to employee identification, such as staff numbers. By default, the username field is not editable by administrators. If your organization requires the ability to manually change user account names, you must contact support@ops-com.com  to request that the Allow Username Edits setting be enabled for your environment. Text2ParkMe Configuration If your organization utilizes the Text2ParkMe module, a second tab will be available on the   User Profile settings page. This tab allows you to configure additional details that end-users can enter, including specific credit card information fields. If any credit card information is entered by the user via the Text2ParkMe tab, the system automatically switches all other credit card information fields to a required state for that specific transaction to ensure payment processing succeeds. Best Practices and Considerations Balance data collection and the user experience: Avoid making too many fields required, as this can create friction and deter users from successfully completing their profiles. Prioritize truly essential information to streamline the registration process. Understand underlying system overrides: Be aware that the system may still require certain fundamental pieces of information even if you attempt to hide them. For example, core identifiers like a username or email address are essential for basic functionality and may override your hidden settings. Configure student address requirements: If you require students to provide both a mailing and local address, ensure you enable the Require Both Addresses for Students setting. Once filled out, admins can view both locations under the Active Addresses section of the user profile. Do not forget to also enable the Using Student Second Address setting so these fields are visible on the admin side. Review hidden fields periodically: Ensure that fields marked as hidden truly remain irrelevant to your current processes. Organizational needs can change rapidly, making previously hidden data suddenly important for enforcement or reporting. Tailor requirements to specific user types: Consider which information is truly necessary for different user classifications. You can configure the system to ask for different identifying details depending on whether the registering user is a student or an employee. Account Creation Preferences The Account Creation Preferences feature allows administrators to choose between granting users immediate portal access or requiring explicit email verification upon registration. Its primary purpose is to balance user convenience with system security and data integrity by controlling the onboarding flow. This article is intended for OPS-COM administrators responsible for managing the user registration experience. Setup and Configuration This feature is a global system setting that immediately dictates the onboarding workflow for all new users. Admin Side: Administrators must have the appropriate system role permissions to access the configuration menus and modify the registration parameters. User Side: Depending on the configured preference, new users will either be logged in immediately after creating an account or prompted to check their email for a verification link before they can access the portal. For complete user-side documentation, please refer to the  Registering as a User article. Using this Feature Administrators can use the following instructions to locate the registration setting and toggle the desired onboarding workflow. Configuring the Account Creation Flow Hover over System Configuration , click System Settings , and click the User Profile tab. Locate the Auto Login After Register setting. Enable the Auto Login After Register toggle to allow immediate login, or disable it to require email verification. Available Configuration States The Auto Login After Register setting has two distinct states, each with specific implications for user experience and system security: Immediate Login (Enabled): This configuration allows users to instantly access their account immediately upon completing registration, bypassing email verification entirely. This method reduces friction and provides a quicker onboarding experience. It is ideal for scenarios where users might not have immediate access to their email, such as dedicated lobby kiosk setups. Email Verification (Disabled): This configuration requires users to click a unique verification link sent to their registered email address before they can fully access their account. This is generally the preferred method, as it immediately confirms the registration originates from a real user with a valid email address, significantly reducing bot registrations and fake accounts. While immediate login reduces friction, requiring email verification establishes a reliable communication channel from day one. This is crucial for securely processing future password resets, executing account recovery procedures, and delivering important system notifications. Best Practices and Considerations Balance security and convenience: Carefully weigh the trade-offs between user convenience (immediate login) and enhanced security (email verification) based on your organization's risk tolerance. Consider the technical literacy and typical access methods of your target audience when deciding on the preferred setting. Ensure robust email deliverability: If you require email verification, verify that your system's global email sending configurations are properly established. This guarantees that verification emails are delivered promptly and reliably, preventing users from getting stuck during registration. Communicate the registration process: Clearly inform users about the account creation process on your portal homepage. If email verification is required, provide explicit instructions reminding users to check their spam or junk folders for the activation link. Maintain regulatory compliance: Consider that data privacy regulations often implicitly favor email verification. Forcing users to verify their email contributes to better data quality and acts as a verifiable record of user consent. Configuring Multi-Factor Authentication on the User Portal Multi-Factor Authentication (MFA) adds a crucial second layer of security to user accounts by requiring one-time passwords (OTPs) sent via email. Its primary purpose is to significantly enhance protection against unauthorized access to the system. This article is intended for OPS-COM administrators responsible for configuring global security settings and managing the user login experience. Setup and Configuration Implementing MFA involves administrator-side configuration within the system settings and customizing the associated email template. Admin Side Configuration One-time passwords will not be available on the user portal until enabled within the global settings. Hover over System Configuration and click System Settings . Navigate to the User Profile tab. Configure the Enable Multi-Factor Authentication setting to your desired state. If the MFA setting is not available for you to change, please have your primary administrator contact support@ops-com.com  to have the feature enabled for your environment. Email Template Configuration The content of the one-time password email sent to users is defined within a dedicated email template. Hover over System Configuration , click Content & Designs , then Email Templates . Locate and click the One-Time Password Email Template to edit its contents. Define the message and insert any relevant organizational branding. Utilize the available shortcodes to insert the OTP details: [one_time_password] : Inserts the randomly generated one-time password. [one_time_password value="issued_at"] : Inserts the time the password was generated. [one_time_password value="expires_at"] : Inserts the time the password expires. Using this Feature Administrators can use the ternary setting to flexibly control how MFA is implemented across the user portal, while users manage their individual settings from their profile. Available Configuration States The Enable Multi-Factor Authentication setting has three distinct states: Hidden: The use of one-time passwords is disabled site-wide. Users will not see or be able to enable MFA on their accounts. Visible: The use of one-time passwords is enabled, but it is left optional for individual users to decide if they want to enable it on their account. Required: The use of one-time passwords is mandatory for all users of the portal. Users who do not have it enabled will be automatically redirected to the setup page upon their next login and must configure it before accessing their account. User Management Users can enable and manage their one-time password settings directly from their security page. For detailed instructions on the user experience, please refer to the  Multi-Factor Authentication - User Portal  wiki article. The state of a user's one-time password verification is stored in the local storage of their session data. If a user clears their browser cache, or attempts to log in using a different web browser or device, the MFA verification wi ll not persist and they will be forced to enter a new one-time password. Best Practices and Considerations Execute a gradual rollout: When introducing MFA, consider starting with the Visible setting to allow users to opt-in voluntarily. Once your user base is accustomed to the feature, transition the setting to the Required state for all users if your organizational security policy mandates it. Verify email deliverability: Ensure that your system's email settings are correctly configured and that OTP emails are not being blocked by institutional spam filters. Users must receive these emails promptly to successfully log in. Communicate OTP expiry limits: Remind users that one-time passwords are time-sensitive and permanently expire after 15 minutes. Generating a new password will automatically invalidate any previous ones, and this system default cannot be changed. Provide clear communication and training: Inform users about the MFA requirement, how to set it up, and how to log in using OTPs. Providing clear instructions and troubleshooting tips on your portal homepage reduces support tickets during the initial rollout. Password and Security Settings The Password and Security Settings feature provides administrators with critical tools to enforce robust password policies and manage login security for all backend administrative accounts. Its primary purpose is to protect sensitive system data, prevent unauthorized access, and ensure organizational compliance with modern security standards. This article is intended for OPS-COM administrators responsible for managing backend system configuration and access security. Setup and Configuration This feature requires high-level administrative access to view and manage global security protocols. Admin Side: Administrators must have the appropriate system role permissions enabled to access the centralized system settings menu. Hover over System Configuration and click System Settings . Click Security to open the management window and view all available security configurations. User Side: This feature dictates backend administrative security and does not directly configure the end-user parking portal login policies. Using this Feature Administrators can use the configuration window to define various aspects of password management, strength requirements, and automated account lockout policies. Password Security Settings Salted Password Hashing: Adds an essential layer of security by irreversibly converting passwords into unique, short hash values with a randomized "salt" string. This ensures that even if two users share the same password, their stored hash values remain completely different. It prevents reverse engineering, meaning forgotten passwords must be reset rather than retrieved. Require Password Update: Forces administrators to change their passwords upon their next successful login. This is ideal for ensuring compliance after a manual password reset. Toggle Password Expiry: Mandates regular password changes. When enabled, enter a numerical value into the Password Expiry in days field to define the exact lifecycle of an active password (e.g., 90 days). Enable Password History: Remembers passwords previously used by an administrator to prevent immediate reuse. When enabled, set the How long to remember old passwords field (in days) to define the restriction duration. Password Strength Requirements These settings allow you to enforce complexity rules for all new administrator passwords: Minimum Password Length: Sets the absolute minimum number of characters required for a valid password. Enable password strength requirements: Toggles specific complexity rules on or off. When enabled, you can set a minimum required character count for Numerical Characters , Lower Case Characters , Upper Case Characters , and Non-Alpha Numeric characters (e.g., !, &, #). Admin Account Lockout Settings These settings provide an automated layer of security by locking an administrator out of their account after repeated incorrect password attempts: Enable Admin Lockouts: Toggles the automated account lockout feature on or off. Lockout after X Attempts: Sets the threshold for failed login attempts with an incorrect password before the system actively locks out the administrator. Login attempt timeframe: Sets the timeframe (in minutes) during which incorrect login attempts are counted. For example, if an administrator fails 3 times within a 5-minute period, their account will be locked out. Lock the admin out for X minutes: Sets the duration (in minutes) that the administrator's account will remain locked. For example, setting it to 120 minutes means the administrator is completely locked out for 2 hours before another login attempt is permitted. Several major security settings (such as Salted Password Hashing, password expiry, and lockouts) are visible to administrat ors but can only be changed by the OPS-COM Team. For modifications to these restricted, read-only settings, please contact support@ops-com.com . Best Practices and Considerations Enable salted password hashing: Ensure Salted Password Hashing is permanen tly en abled for maximum password security. Once enabled, this setting should never be turned off, as doing so reopens a critical security vulnerability and allows administrators to view raw employee passwords. Maintain a robust security policy: Always implement a comprehensive security policy that combines strong password requirements, mandatory expiry limits, and lockout mechanisms. Enforce regular password expiry: Enforce regular password expiry intervals (e.g., every 90 days) to mitigate the risk of compromised credentials. Stale passwords are a primary vector for unauthorized access. Configure meaningful lockout settings: Configure lockout settings to balance strict security with user convenience. Overly aggressive settings can lead to constant lockouts and administrative overhead, while lenient settings fail to prevent active brute-force attacks. Communicate policies to staff: Inform administrators about the security policies in place, including password strength requirements and lockout procedures. Clear communication helps staff comply and understand exactly why they might be temporarily locked out of the system. Uploading and Managing Files The Manage Files feature provides a centralized repository for all files used across your application, primarily focusing on images for user and admin dashboards. Its primary purpose is to allow administrators to easily upload, view, organize, and manipulate visual content to ensure consistent branding throughout the system. This article is intended for OPS-COM administrators responsible for managing system content and visual assets. Setup and Configuration This feature is a core administrative tool used to store and manage system-wide assets. Admin Side: Administrators must have the appropriate system role permissions enabled to access the configuration menus and modify system files. User Side: This file manager is strictly a backend administrative tool; however, the uploaded files (such as logos, banners, and permit images) are ultimately visible to end-users on the parking portal. Using this Feature Administrators can use the following instructions to navigate the file manager, upload new assets, manipulate existing files, and embed images directly onto custom pages. Accessing and Viewing Files Hover over System Configuration and click Manage Files . Select your preferred viewing layout from the interface: Grid Mode: Displays a visual thumbnail preview of each image, which is highly useful for quickly identifying visual content. Table Mode: Provides a detailed list view, displaying file names, sizes, and other relevant information. Adding Files to the Repository Click the Upload tool to open the file upload interface. Click Select files and choose the desired images from your local device. Click Submit to upload the files directly to your site's storage. Once an image is successfully uploaded, it cannot be moved to a different folder. To maintain proper organization, ensure you navigate to and open the intended destination folder before you upload the image. Managing Existing Files Right-click on a specific image or file to open a contextual menu. Click Download to save a copy of the file to your local device, Rename to change the file name, or Delete to permanently remove the file from the system. Click View on an image, then click the Cropping icon to open a tool that allows you to resize or adjust the visible dimensions to focus on a specific area. Adding Images to a Page Click Insert in the text editor toolbar when editing a custom page or content area. Select Image from the dropdown menu. Click the search folder icon next to the source field to open the file manager. Locate and double-click the specific image you wish to insert. The image will immediately be added to the page at the location of your cursor. Best Practices and Considerations Organize files using sub-folders: Consider creating sub-folders within the file manager to keep your assets organized and easy to locate. Because uploaded files cannot be moved once added, establishing a clean folder structure early prevents repository clutter. Use descriptive file names: Always use clear and descriptive file names to simplify identification and referencing. For example, naming an asset company-logo-header.png is significantly better than a generic name like image1.png . Optimize image sizes: Before uploading, optimize large images for web use. Smaller file sizes will drastically improve page load times for both the administrative backend and the end-user interfaces. Backup critical assets: Consider maintaining local backups of critical branding assets as a best practice. While the system securely manages these files, having local copies of standard organizational logos and banners is always recommended. Ensure path accuracy: When manually linking images to pages via HTML, ensure the URL path is exactly correct. File paths are often case-sensitive, so capitalization and spelling must perfectly match the uploaded file name. Admin Dashboard Setup (Quick Start) The OPS-COM Dashboard is a fully customizable, widget-based analytics interface built directly into the admin portal. Its primary purpose is to allow administrators to create tailored data views, arrange widgets freely on a drag-and-drop grid, and configure specific metrics to monitor daily operations. This article is intended for OPS-COM administrators seeking a brief overview of dashboard capabilities. Setup and Configuration Configuring personal dashboards and setting up widget layouts requires specific backend access. Admin Side: Administrators must have the appropriate administrative permissions enabled within their user role to access, configure, and save dashboard layouts. Using this Feature Administrators can use the dashboard interface to construct personalized, real-time views of system data. Customizing the Dashboard Navigate to the main dashboard interface within the admin portal. Create multiple personal dashboards to separate different types of data. Arrange widgets freely on the provided drag-and-drop grid. Configure each widget individually to show exactly the data you need for your daily workflows. Dashboard layouts and widget configuration are fully documented in our comprehensive feature guide. For detailed instructions on available widgets, deep customization, and advanced layout options, please refer to the Using the OPSCOM-ARC System Dashboard & Widgets article. Best Practices and Considerations Utilize automatic refreshing: Set your dashboards and widgets to automatically refresh on a configurable schedule. This ensures your analytics are consistently up-to-date without requiring you to manually reload the page. Design for mobile responsiveness: Take advantage of the system's responsive design. Dashboards and widgets are fully responsive down to mobile widths, allowing you to easily monitor system metrics and enforcement operations from a smartphone or tablet. Organize with multiple dashboards: Create multiple personal dashboards tailored to specific operational tasks. Instead of cluttering a single screen with too much information, separate your widgets logically (e.g., maintaining one dashboard for financial metrics and another for daily enforcement activities).