Your Data Is Yours:
No Lock-In
This is the question enterprise buyers wonder about most and ask about least. The answer is not a marketing line — it is the architecture itself: you can take out your data, and the structure of your data, at any time.
“If we walk away, what happens to our data? Are we locked in?” This page answers exactly that question, at the mechanism level.
You can export your data at any time
In 361, export is not a feature bolted on afterwards — it is a standard capability of the data layer. Transfer is bidirectional: data does not only come in, it goes out in the same formats.
Bidirectional data transfer
Import and export in CSV, Excel, JSON and XML run through the same engine. Getting data out does not require a separate module, a separate request or custom development.
Report and analysis outputs
Analysis results can be exported as multi-sheet Excel files, presentation files and PDFs with rendered charts. So it is not only the raw rows that leave with you — the interpretation and visualisation you built leaves too.
Your schema is programmatically readable
Entity types, fields, related fields, states and the metadata version can be queried through the core API.
Alongside the data, the structure of the data is yours — you never have to rediscover what a field means.
Relationship graph as JSON-LD
The network of relationships between records is exported as JSON-LD. This is a standard semantic format; it can be carried into other tools and graph databases.
File access over WebDAV
Documents and attachments are reachable over WebDAV, and content can be downloaded in parts. You do not have to wait for one enormous archive.
Outage resilience
The second question people ask quietly: “If the vendor's server goes down, does our business stop too?” A 361 installation does not depend on a live connection to a central service.
An installation-specific key pair
Every customer installation has its own RSA-2048 key pair. Identity and entitlement verification happens with the installation's own key.
Entitlement carried by a signed manifest
Entitlement information travels in a signed manifest file. Even if the central server is unreachable for hours, the installation keeps running.
Not a promise — a consequence of the design
Continuing to run is not the result of a sentence in a contract; it follows from verification being done locally. When the connection drops, the system does not need to reach out “to ask permission”.
Your data stays in your own space
The sibling of lock-in anxiety is commingling anxiety: “Is our data sitting in the same pool as other customers'?” Isolation follows the same boundary from storage all the way up to the AI layer.
Per-space storage
Usage and cost data is kept in each customer space's own directory. One space's data cannot be reached from another space.
Keys stored encrypted
The keys used to connect to external systems are encrypted per space with AES-256; they are never written in plain text.
Integration connections isolated
Integration connections are isolated per space. One customer's connection definition is not visible or usable in another installation.
Channel events do not spill over
Messaging and channel events are processed under space protection; events from one space cannot spill over to other customers.
Row-level security applies to AI too
Row-level access security applies not only to the user at the screen but to the AI as well. An agent cannot see a row the user cannot see — neither when summarising, nor when answering.
The right to erasure
Being able to take your data out matters as much as being able to have it erased. Erasure runs as a controlled process, not as one irreversible click.
A 30-day cooling-off window
When an erasure request under data protection law is recorded, a 30-day cooling-off period begins. The request can be cancelled within that window, so a mistaken decision can be corrected.
Deterministic anonymisation
When the window closes, records are anonymised deterministically. The link back to the individual is severed permanently, while the numeric traces needed for organisational integrity remain identity-free.
Masking in audit records
Sensitive fields are masked in audit records. “Who did what” stays traceable, while sensitive content never lands in log files as plain text.
If you walk away — four steps
Writing down the exit scenario before the purchasing conversation is the healthiest approach. The process has four steps.
-
1
Export
Data and schema are taken out in standard formats: records as CSV / Excel / JSON / XML, the structure definition through the API, the relationship network as JSON-LD, files over WebDAV. What you are left with is not a proprietary format but a portable data set.
-
2
Disconnecting the integrations
Integration connections to external systems are disabled one by one. Your source systems have not changed in the meantime — 361 does not replace them, it runs on top of them.
-
3
Handing the processes back
Because 361 is a layer placed on top, the systems underneath keep running. Steps that were handed to automation return to how they worked before it; the system underneath was always the owner of the data and the workflow.
-
4
Closing
The installation is terminated and the erasure request is executed: the 30-day cooling-off window, then deterministic anonymisation. Closing is a dated process, not an open question.
Because 361 does not replace the systems underneath, the cost of leaving is not the same thing as replacing a core system.
What we do not promise here
Everything on this page is about how the product works. Contractual matters should not be committed to with numbers on a marketing page; their place is the contract discussion.
- Source code escrow — if such an arrangement is required, its scope, triggers and parties are discussed as part of the contract. It is not presented here as a commitment.
- Uptime percentage (SLA) — service level targets vary with the deployment model (your own servers, OneBox, hosted); no figure is stated here, it is discussed as part of the contract.
- Recovery time objective — disaster recovery timings and the backup regime depend on your own infrastructure; they are discussed as part of the contract.
- Why we draw this line — behaviour that comes from the architecture (export, isolation, local verification) is identical in every installation. Contractual commitments are specific to each organisation. A page that blends the two is not a trustworthy page.
Where to read more
For technical security measures, personal data processes and questions specific to your organisation:
Last updated: July 2026