Security and data ownership
Manage network information as your organisation’s own record. Assess access, change tracking and data portability alongside your deployment decision.
Your organisation’s information, your organisation’s record.
The network data you hold in SoSoMaps belongs to your organisation. Map features, connections and project information support daily work, internal reporting and data portability. Authorised users can access output and export options appropriate to their responsibilities.
Export drawings and geographic records as DXF, KML and GeoJSON, and inventory lists as XLSX. Field lists and reports have their own output options. Use the same project information as drawings, tables and field documents.
Choose the entire project or the visible area for export, and specify the feature types to include. These choices define the content of files shared within your organisation. Hiding a map layer does not automatically define the export scope; review the export selections separately.
A project package moves map features, supported devices, connections and project settings to another empty project. Keep the original contents of photo, document and measurement files separately. User accounts and the complete work history are outside the project package; define your organisation’s backup arrangements separately.
When an on-premises deployment enters read-only mode because of its licence status, permitted viewing, search, reporting and export remain available. Service continuation, access and data handover terms are defined in the agreement.
Match access to project responsibilities.
User roles separate organisation administration from responsibility for editing data. The organisation administrator manages users and organisation settings; team members with editing permissions work on the project records they are allowed to change. The Viewer role supports viewing and outputs without changing data.
Open a project to organisation users or define access through project membership. Organisation administrators can access their organisation’s projects. Project membership does not extend the permissions granted by the organisation role; both sets of responsibilities apply together.
Use writable module and region selections to define the records teams can change. These selections do not hide readable data by region. Plan sharing through project access and working areas through write permissions.
Keep access aligned with current responsibilities.
The organisation administrator can deactivate a user account and end its active sessions. When users change their own password, their other sessions end. An administrator’s password reset also ends the account’s existing sessions. This supports access updates as teams and responsibilities change.
Create access keys linked to a user for other applications. Define their project scope and whether they allow write access, and revoke them when required. A key cannot exceed its owner’s current permissions. Revoking an unneeded key allows the user account to remain available for other work.
The key secret is shown only when it is created. The organisation administrator can view and revoke keys within their organisation. When a connection’s purpose or scope changes, create a new key with suitable permissions, update the connected application, then revoke the old key. This keeps application connections linked to their responsible people within the organisation.
See where record changes came from.
Project history shows data operations with the user, time, description and affected records. Teams can review which records an import or edit changed. Keeping related changes within one operation helps assess the scope of the work.
Authorised users can undo eligible operations through the history. Later changes and record relationships affect whether an operation can be undone; the application’s check result determines the outcome. Design changes enter the main project record after review and approval.
Keep shared information within its permission scope.
The documented API uses the access key’s scope when sharing project data with your organisation’s other applications. Read and write requirements can be defined separately. Changes to a user’s permissions or project access also affect the key’s available scope.
WMS and OGC API Features publish authorised project records as read-only data. Webhook notifications send signed project events. The receiving application verifies the signature, and delivery status can be checked in the relevant records. Your integration team can review these contracts in the public developer documentation.
Choose your data location through deployment.
Cloud
Access SoSoMaps through a web browser. Your data is hosted in data centres in Türkiye. Backup terms are defined in the agreement.
On-premises deployment
The application is installed on your organisation’s infrastructure and can also be used without an internet connection. Installation, access and backup responsibilities are defined around your organisation’s requirements.
Assess user roles, data import, access requirements and expectations for data leaving your organisation when choosing a deployment. Organisational terms are set out in the relevant agreement.
Let us assess your organisation’s requirements together.
Define your deployment option, data import and access scope.
