Employee Accounts & Privacy Requests

Employer-provisioned employee accounts

The current CabNexus Driver deployment is restricted to authorised NANUAN’S employees, who work for NANUAN’S only. The app is for signing in with existing employer-managed credentials. NANUAN’S provisions accounts and arranges initial access outside the Driver app; the app has no public registration or link to create an account. CabNexus is a product of SoftDots Technologies. The Privacy Policy identifies the employer and its business contacts.

Employment status, a leaving date, access authorisation, retained records and permanent deletion are separate matters. A fleet administrator manages work access; that role does not give an unexplained blanket veto over a lawful personal-data request.

The employee record, linked login account and associated personal data are distinct. The employee-management screen provides status, operational-availability and access controls, without an employee-record delete control. Separate permanent-deletion and privacy-request routes remain available below; the absence of a delete button in that screen does not decide the outcome of a personal-data request.

When employment or authorisation ends

Employment status records whether the employee is currently employed (active) or is a former employee (inactive). Leaving date and reason record departure. Marking an employee inactive or changing leaving details does not automatically disable or reset application login.

Operational availability is separate from employment status and login. In the assignment workflows, “Record enabled for operational use” must be enabled to create a driver profile or give that employee a new taxi or booking assignment, including replacement or reallocation. The current state is checked when an assignment is submitted. Enabling it does not grant application login or bypass other availability checks.

Disabling operational use does not automatically cancel or reassign existing or scheduled work. The employer must review it and arrange any necessary changes. Authorised users can release work, reassign it away from that driver or complete existing work under the usual permissions and work controls. The employee record and historical transactions are not deleted by the flag change.

An authorised administrator must separately disable application login when access is no longer permitted. In the offboarding workflow, explicit confirmation rejects sign-in and protected requests on their next server check, invalidates existing credentials and recorded sessions, and clears the current push registration. An offline device learns about the restriction when it reconnects. Neither an employment-status edit nor an operational-availability edit performs that action.

This deployment supports one employer per employee account. If an account also has separate administrative or other access, or its relationships are unclear, an administrator must review the access before offboarding. Recording that review does not change access or override the offboarding checks. Rehire requires separate authorisation and new credentials; it must not restore old sessions.

The employer retains the employee record and linked historical trips, duties, attendance, allowances, expenses, reimbursements and settlements for accurate operational history, reconciliation, reporting, audits and dispute handling, subject to relevant retention criteria. Removing the employee record could detach employment details from those transactions. Offboarding, inactive status and operational disablement do not delete that history or establish permanent account deletion. Signing out and uninstalling are also different from server-side deletion.

Requests from current and former employees

Current and former employees can email support@softdots.in to request access, correction, information about retention, deletion or anonymisation where applicable, or review of a refusal or retention exception. Identify the request, fleet, account username or telephone number, and a reply address. You do not need account access or to reinstall the app to use this route.

Do not include passwords, OTPs, private request-status codes or identity documents in the initial email. Verification should use information already associated with the account where possible and request only what is necessary to distinguish and verify the requester.

SoftDots and the fleet may need to coordinate who holds a record, who is responsible for the processing and which obligations apply. A response should identify a retained category, its specific reason and end date or measurable review criterion, and how to ask for review. Product ownership alone does not decide every legal role; applicable arrangements and law govern those responsibilities.

Request permanent account and personal-data deletion

You can submit a voluntary permanent-deletion request for review. In CabNexus Driver, open Profile, then Permanent account deletion. In the fleet web workspace, open Account, then Privacy and account deletion, and choose Request permanent account deletion. Read the consequences, enter your current password and type DELETE MY ACCOUNT. Submit using Request permanent deletion in the app or Submit deletion request in the workspace. Submission records or returns your request; it does not immediately erase records or close your account. Necessary retained-record exceptions are explained below.

Save the request reference and private status code. The app and fleet sign-in screens provide a deletion-status option that works after account access ends. The code is private and must not be put in a URL or email. When the replacement option is available, confirming the same request again while signed in replaces the previous code rather than creating a second request; its existing processing status is preserved.

If the controls are unavailable or you cannot sign in, email support@softdots.in with the subject “CabNexus permanent account deletion”, state what you want permanently deleted and include the identification and reply details above. Requests about particular personal information are also accepted. A request may require a category-specific retention review; disabling login alone is never confirmation of permanent deletion.

Review, timing and completion

The request controls record a request and provide an on-screen acknowledgement, reference and status. Identity confirmation and assessment of the affected records are separate from completed deletion. Automatic erasure is not enabled as part of the current request service; submitting a request is not a promise that every employee or transaction record will be removed.

There is no single completion period for every request. Contact support@softdots.in for the handling and timing that apply to your request, including any applicable legal deadline. Identity checks, retries or revised estimates must not reset an applicable deadline. No fixed live-system, provider or backup-removal timetable is promised on this page.

Use the reference and private code to check the available status without signing in, or contact support@softdots.in. The request controls do not themselves send automatic delay or completion emails. A recorded request, identity check or pending step is not confirmation of erasure.

A response to the request must distinguish removed or anonymised information from records retained for an identified purpose, with a reason and retention end date or measurable review criterion. A blocked or incomplete step, provider acceptance or pending backup expiry must not be reported as completed deletion.

Category-specific retention and shared records

Identity and employment details, licences and eligibility, attendance and assignments, payroll-related expenses and settlements, and invoices and payments have different purposes. An outstanding transaction, identified dispute or specific accounting, employment or other legal obligation can justify retaining identified records. Employment alone is not a reason to retain every field indefinitely.

Covered GST invoices, accounts and necessary supporting records may remain after employment ends or an authentication account is closed. The Data Policy explains the statutory period, its annual-return due-date starting point and extensions for specified proceedings. This does not require an active login or justify keeping every employee field indefinitely.

Precise coordinates, device identifiers, original photos, receipts and OCR text require their own necessity review. Preserving an attendance decision or invoice must not automatically preserve every source image, location point or unrelated personal detail. Access to retained history is limited to authorised responsibilities; disposal or anonymisation is due when the identified justification ends.

Requests are reviewed with regard to shared bookings, passengers, other workers and fleet records. Those records are not deleted indiscriminately. Where retention is justified or removal cannot be completed, you can ask for the specific reason, review criterion and review of that decision. The Data Policy explains the categories and limits.

Local copies, providers and recovery

The clients stop protected work and clear supported sensitive local session data when access revocation is confirmed. Offline devices, browser storage failures, temporary files and copies already delivered or exported can require separate handling. This does not remove provider installations or prove that every device copy has been erased.

Backups, snapshots, replicas, storage versions and service-provider copies can remain after a live record changes. Removal or expiry of the copies covered by a request must be confirmed before that work is reported complete. No fixed backup-removal period is promised.

Access and approved deletion restrictions must also apply when information is restored from backup. A minimal protected request or recovery record may be retained to document the outcome and prevent a restoration from reversing it. This does not justify indefinite retention of unrelated source data.