Evaluating Flexday AI
Portability and exit
How to move or leave Flexday AI - Solution and resource exports, the open formats underneath, deletion and teardown, and what happens at the end of a contract.
- Functional users
- Technical
Last reviewed
A buyer should know before adopting a platform how they would leave it. In Flexday AI everything a Solution contains can be exported to one bundle file, single resources can be exported on their own, and what the platform builds is made of open formats: PostgreSQL schemas, plain web files and JSON definitions. This page describes the platform's side of an exit: what you can take, in what form, and what is deleted when you go. Contract terms for an exit, such as notice periods or assistance, are for your agreement with Flexday.
At a glance
- One bundle per Solution. Every resource always travels; you choose which data goes with it.
- Secrets never travel. Credentials and secret values are left out of every export.
- Open formats. Datasets are PostgreSQL schemas queried with SQL, apps are HTML, CSS and JavaScript files, and definitions are JSON.
- Deletion is real. Deleting a Solution removes what it owns, and an offboarded workspace is purged, down to its encryption key.
Exporting a Solution
A Solution's Exports view writes one bundle file, a zip archive, to a File Store you choose, in a background job. The bundle always carries every resource the Solution owns, and each kind of data is a choice of its own: Fact Base rows, documents, files, and run and conversation history. Choices that depend on each other are switched on together and say why (documents need their files). Non-secret Variable values travel; credentials and secret values never do.
Importing a bundle always creates a new Solution, with new ids and every internal reference remapped, and never merges into or overwrites an existing one. A Flow step that calls one of the Solution's own gateways by its full web address is repointed to the new copy; a call to a gateway the bundle does not carry is left as written and listed in the import report. Flows arrive switched off and Bots unregistered, a webhook Flow gets a new address and signing secret, and the import report lists each credential to re-enter and each Variable to fill in. A bundle that needs a newer release than the importing one is refused before anything is created. An import that fails with an error removes what it created; if the worker running it stops partway, the import is marked failed and a partly created Solution can be left behind to delete. See Data lifecycle and portability.
Exporting a single resource
| Resource | What the export holds |
|---|---|
| Fact Base | Its definition, its custom roles and its sample data, within a size limit; it arrives unprovisioned, ready to create its schema. Live rows travel in a Solution export. |
| Flow | Its graph and the Variables it needs, without any credential |
| Agent | Its definition, including instructions, grants and guardrails, and the Variables it needs |
A single Flow or Agent is imported as a new draft into a Solution you choose. If that Solution already has a Flow or Agent of the same name (ignoring capitals), the import is refused and nothing is created.
The formats underneath
| What you built | Its format | Outside the platform |
|---|---|---|
| Fact Base | A PostgreSQL schema of its own, with its definition as JSON | Readable with standard SQL; in a dedicated deployment the database is in your own account |
| Saved queries | SQL with declared parameters | Plain SQL |
| LaunchPad apps | HTML, CSS and JavaScript files, with no build step | Readable as they are; they call the platform's gateway for their data and sign-in |
| Flows and Agents | JSON definitions | Readable as they are; they run on the platform's engine |
| Documents and files | The files you uploaded, in their original formats | Downloadable from their File Store |
| The API | A generated OpenAPI description | Usable by any OpenAPI tooling |
Deletion and teardown
- A Solution. Deleting it cancels its Flow runs, ends its Agent conversations, unregisters its managed Teams Bots, deletes its document indexes and files, removes its records, then drops its Fact Base schemas and app files. Each clean-up step runs even if an earlier one fails; if removing the records itself fails, the delete stops before the Fact Base schemas and app files are dropped. The audit trail and the file access log are kept.
- A workspace. An owner can offboard it. Access stops, running work is cancelled and a final export is made. After the workspace's retention window (30 days by default), during which it can be restored, the workspace is purged: every schema, stored file and record is deleted, the audit trail last, and the workspace's encryption key is destroyed.
- What a purge cannot reach. Backups and earlier object versions expire on their own schedule (see Reliability and business continuity), and a Teams app registered in your Microsoft tenant is yours to remove. On a deployment set to keep Secret Variables in a cloud vault, their copies there are removed when each Variable is cleared, changed or deleted, not when its Solution is deleted or its workspace purged.
At the end of a contract
On the platform side, an orderly exit looks like this:
- Export each Solution with the data you need: rows, documents, files and history.
- Download anything else you need from File Stores, and record the Variables and settings you will recreate elsewhere.
- Offboard the workspace. The final export it makes holds the workspace's records as JSON and each dataset's rows as JSON, table by table (the dataset definitions are among the records); it does not hold file contents, which is why step 1 matters.
- Confirm the purge after the retention window, and remove what the purge cannot reach.
A dedicated deployment keeps all of its data in your own cloud account throughout, so an exit there is a decision about the deployment itself. Ask Flexday what its contract provides for exit assistance and for the time after it ends.