Data Policy

Records and responsibilities

CabNexus is a product of SoftDots Technologies. It connects bookings, drivers, vehicles, attendance, assignments, fuel and odometer evidence, duties, invoices, payments and operational reports. For privacy and business requests, contact support@softdots.in.

The current CabNexus Driver deployment serves NANUAN’S own employees only. NANUAN’S provisions and manages accounts; public driver self-registration and separate multi-employer access are unavailable. The employer controls work authorisation and operational instructions and must provide appropriate notices to workers and passengers. SoftDots owns the product; actual service arrangements and applicable law determine processing responsibilities. Users should supply only relevant information and use records and exports within their permissions.

Account, profile and authentication records

An employee record holds employment details and links to work history; the linked authentication account controls application login. Active employment status means currently employed, while inactive means a former employee. Leaving date and reason record departure. Licences and eligibility support authorised driving work. These records need identified purposes, restricted access and their own retention criteria.

Operational availability is managed separately through “Record enabled for operational use”. The workflows check the current employee state when creating a driver profile, assigning or replacing a driver’s taxi, and allocating or reallocating a booking to that driver. A disabled record blocks those new assignments; enabling it does not grant login or bypass other driver, vehicle and scheduling checks.

Existing and scheduled assignments are not cancelled or reassigned automatically when the flag changes. The employer must review them and arrange changes where needed. Release, reassignment away from that driver and completion of existing work remain subject to the usual permissions and work controls; historical records are preserved. The employee-management screen has no employee-record deletion control and does not replace the separate personal-data request routes.

Changing employment status, leaving details or operational availability does not automatically enable, disable or reset application login. An authorised administrator must separately disable login when access is no longer permitted. Mixed-role or unclear relationships require review; a recorded assessment cannot change access or override offboarding checks. Rehire requires separate authorisation and fresh credentials.

Access tokens, refresh tokens, notification tokens and browser sessions have separate functions. Authentication expiry is not a personal-data retention period. The separate login-disable action rejects sign-in and protected requests on their next server check, invalidates existing credentials and recorded sessions, and clears the current push registration. Explicit offboarding also applies its supported queued-work restrictions. Login disablement alone does not cancel every queued message or background task, recall delivered notifications, or erase provider-held identifiers and device copies.

Attendance and location evidence

Attendance and odometer submissions can contain coordinates, accuracy, capture time, device or installation information and review history. The driver capture flow requests foreground location when used. Attendance capture requires it; odometer photo submission supports omitting coordinates when permission is declined or location is unavailable, without substituting a false location. Earlier app versions can differ. This evidence can be needed to review a submission, correct an attendance decision or resolve a specific associated work or payment dispute.

Reviewing a record or ending a shift does not automatically erase location evidence. Coordinates and device identifiers require a separate necessity review from the shared attendance or duty decision. Keeping that decision does not by itself justify retaining every supporting field.

Photos, receipts and OCR

Photos, fuel receipts, odometer readings and OCR fields support the associated submission and review. They can remain relevant while an identified expense, reading, correction or reimbursement is unresolved. Original images, extracted text and derived files are separate copies. Removal requires reviewed ownership and reference checks; a shared or unreviewed file is not indiscriminately deleted.

The driver app validates the original odometer photo before making an upload copy that strips embedded location and device metadata and preserves its visible orientation. The capture time and any permitted coordinates are separate submission fields. The original device file and the temporary upload copy have separate local lifecycles; this process does not establish their automatic deletion. Historical images and other upload routes require their own metadata review.

Uploaded files are held in the fleet’s configured server or cloud storage. When document extraction is enabled, processing can take place on the server or through an external extraction service; an external processor receives the relevant image content. Ask support@softdots.in which storage and processing services apply to your records. Removing a live file or signed link does not establish removal of older storage versions, replicas or processor-held copies.

Duties, bookings, expenses and billing

When an employee leaves, their employee record remains linked to historical trips, duties, attendance, allowances, expenses, reimbursements and settlements. Retaining those links preserves operational history, financial reconciliation, reporting, audits and dispute handling. Marking the employee inactive, recording a leaving date or disabling login does not delete that history. Removing the employee record could detach employment details from the associated transactions.

Retention must serve relevant accounting, employment, legal or documented operational requirements. Invoices, payments, payroll-related expenses and other records can have different grounds. Each category needs its responsible organisation, access restrictions, specific purpose and retention end date or measurable review criterion; departure alone does not supply a statutory period. Retaining a transaction does not automatically justify indefinite retention of every source photo, coordinate, device identifier, authentication token or unrelated personal detail.

These are category-specific reasons, not a blanket indefinite business-need exception. Other people’s records and unsettled fleet transactions are not deleted indiscriminately. You can ask which categories are retained, the specific reason, and their retention end date or measurable review criterion.

Section 36 of the Central Goods and Services Tax Act generally requires registered persons to keep the books and records covered by Section 35(1) for 72 months, counted from the relevant financial year’s annual-return due date. This period does not start on the invoice date or the employee’s leaving date. Records concerning the appeals, revisions, proceedings or Chapter XIX offence investigations specified in Section 36 must be kept until the later of the normal period or one year after final disposal. Other applicable obligations may require longer retention.

GST record rules also cover relevant invoices and supporting documents, electronic correction records, backups and the ability to produce electronic records. Necessary transaction links may therefore remain after an employee leaves or an authentication account closes. These rules apply to covered records, not every employee field, photo, coordinate, device identifier or token, and do not require an active login account. The employer’s accountant must identify the covered records, relevant financial year, applicable annual-return due date, proceedings and any longer obligation.

Logs, caches, local copies and backups

Technical logs support investigating an identified failure, misuse or security incident. Their expiry depends on the logging configuration; the application does not establish one universal log or backup retention period. Expiry of a message in a transport system does not erase the source database record.

The fleet browser workspace uses local drafts, print payloads, preferences and short-lived API read caches. A read-cache entry becomes stale after its configured validity, but its bytes may remain until replaced or cleared. See the Cookie Policy for names and clearing controls. Clearing browser data removes local copies, not the fleet’s server records.

Backups and service-provider copies can outlive changes to live records. Removal or expiry of affected copies must be confirmed before a request is described as complete; automated backup expiry does not establish removal of separate snapshots, exports or replicas. Approved access and data restrictions must also apply to restored information. No universal log or backup-removal period is promised.

A minimal request and recovery record supports status checks, justified retention and prevention of restoring deleted information. It uses request references and protected account linkage rather than copies of passwords, original photos or raw notification/status tokens. Its lifecycle depends on outstanding processing, justified retention and recoverable copies. The Driver app saves a private request-status code securely, separately from sign-in credentials, until you remove that saved code or clear app data. The fleet browser status form keeps its code only in memory and clears the input after a check.

Access, corrections, retention and deletion requests

Use your fleet’s correction workflow for a wrong booking, attendance entry, expense or reading. Reviewed or issued records may require a controlled correction rather than an overwrite. Access to reports and exports depends on the module and your permissions.

Current and former employees can request access, correction, retention information, deletion or anonymisation where applicable, and review of a refusal at support@softdots.in. See Employee Accounts & Privacy Requests for email and in-account request routes. The request controls provide a reference and private status code; recording or verifying a request is not completed deletion. Automatic erasure is not enabled as part of the current request service, and no universal completion period is promised. Fleet coordination identifies shared records and obligations; it does not give an administrator a general veto over a lawful request.

The outcome of a request must distinguish removed or anonymised information from narrowly retained records and their reason and period or review criterion. Provider acceptance, pending backup expiry, deactivation and a recorded request are not complete erasure. To report a suspected disclosure, identify the affected record where possible without sending credentials, your private status code or unrelated personal documents.