Export & Import Workspaces

Export one or more workspaces as a single .zip file and import them again, into the same account, a different account, or a fresh InfoLobby install. Use this to back up your work, hand a template to a colleague, or duplicate a working setup as the starting point for a new project.

The archive is self-contained: tables, fields, records, attachments, views, reports, webforms, and flows are all bundled together. It also records which integrations (an SMTP server, an OpenAI key, an API connection) the automations need, so the import can walk you through connecting them instead of leaving you to find the broken flows later.

What's included

  • Schema: every table you choose, with their fields, settings, and any tabs.
  • Records: optional. Toggle "Records (data)" off if you only want the structure.
  • Attachments: optional. File-field uploads, email attachments, and images embedded in rich-text fields are bundled inside the zip; embedded image links are rewritten to the new workspace on import.
  • Comments & emails: optional. Comments and email threads attached to records.
  • Flows: optional. Both visual (drag-and-drop) and code-mode (PHPScript) flows.
  • Views, Reports, and Webforms: always included with the tables they belong to.
  • Sub-tables (master-detail): a table's sub-tables always travel with it. Select a master and its detail tables are bundled in automatically. The master-detail relationship, rollup fields, and record-view tab layout are preserved on import.
  • Multiple workspaces: one archive can carry several workspaces at once. Links between tables in different workspaces are preserved as long as the workspaces you import into share a database (they always do on our managed database).
  • Raw SQL dump: optional. A mysqldump-style .sql file per workspace, covering the tables you selected. See below.

Raw SQL dump

Tick Raw SQL dump (.sql) and the archive also carries a plain CREATE TABLE + INSERT file per workspace, the kind of thing mysql < dump.sql understands. Use it to load your data into your own MySQL, hand it to a DBA, or keep a backup that does not depend on InfoLobby at all.

If that is all you want, untick Records, Attachments, Comments and Flows. You get a small archive containing just the dump and the table definitions.

The dump is for use outside InfoLobby. Importing an archive never reads it: a restore rebuilds your workspace from the structured files, so your fields, views, reports and flows come back with it.

Requirements

Automations often need a connection: a flow that sends email needs an SMTP server, a flow that calls an AI model needs an OpenAI key, an API Request step needs the API connection it was built against. A table with record email enabled needs an SMTP server too.

The archive records each of these by name and type. It never carries credentials.

When you import, the Requirements section lists every connection the archive needs, and what uses it. For each one you either:

  • pick one of your existing connections of the right type, or
  • click Set up…, which opens the connection form in a new tab, pre-named and pre-filled. When the archive can tell which provider a connection points at (Reddit, Stripe, SendGrid and so on) you get that provider's own setup screen, with its endpoints filled in and its step-by-step instructions. Enter your own password or key, save, come back, and click Recheck.

If you have no connection of the right type yet, the row says so plainly rather than showing you an empty dropdown.

The Import button stays disabled until every requirement is resolved. That is deliberate: a half-connected import produces automations that look fine and quietly fail.

Setting up a new connection is always offered, even when you already have one of the right type. Use it when you want imported automations to run through their own connection rather than an existing one.

What's NOT included

  • Credentials. Passwords, API keys, and OAuth tokens never leave your account. Only the name and type of each connection travel, so the import knows what to ask for.
  • History / activity log entries from the source workspace.
  • Embedded webform links: webform IDs are regenerated on import, so any forms you've embedded on external websites need to be re-embedded.
  • External lookup fields: if a lookup points to a table that was not included in the archive, you can map it to an existing table in the same account/database. Unmapped fields are omitted and their record values are discarded.
  • Calc fields referencing tables outside the import: formulas that reference another table (e.g. @{tbl:item_count} or @{tbl:sum:field}) are rewritten to the new target IDs automatically when the referenced table is included or reused during import. If a referenced table isn't available, the calc field is dropped and a warning lists it by name.

Exporting

  1. Open the Workspaces page.
  2. Either click the … menu on a workspace card and choose Export… (admin only), which pre-selects that workspace, or choose Export Workspaces… from the org-level menu to start with a clean slate.
  3. Tick the workspaces you want. Each row shows how many of its tables are selected; click the arrow to open it and pick individual tables. Opening the dialog from a workspace card starts with that workspace expanded and everything ticked, and scrolls it into view if the list is long.
  4. Toggle Records, Attachments, Comments, Flows, and the raw SQL dump.
  5. Click Export. A progress modal streams updates while the archive builds.
  6. The browser downloads the .zip when finished.

Importing

  1. From the Workspaces page, click Import Workspace… in the org-level menu, or Import… in a specific workspace's … menu.
  2. Choose the .zip archive.
  3. The system reads the archive and shows:
    • The size of the archive (tables, records, attachments)
    • The connections it requires, and what uses each one
    • Any code-mode flows that will be imported verbatim and need manual review
  4. Choose the destination:
    • New workspace: gives the import a fresh workspace name. If your account has external MySQL integrations, choose the database and storage to use; the form starts with your newest workspace's choices.
    • Merge into existing: adds (or replaces) tables in a workspace you already own.
    • If table names collide during a merge, choose rename, skip, or overwrite.
    • If the archive carries several workspaces, you get one choice per workspace. New workspaces are created on the same database as the first one, so links between them keep working.
  5. Resolve every entry in the Requirements section.
  6. Click Import. A progress modal streams updates while everything is recreated.
  7. When done, the page reloads on the new (or merged) workspace.

Cross-account portability

Archives are account-agnostic. The source account ID, user IDs, and API-key references are stripped during export. Anything created on import is attributed to you (the importing user). User mentions in old comments are preserved as plain text but no longer link to a profile.

Code-mode flows

Flows that use raw PHPScript are imported as written. Connection names spelled out in the code are updated to match the connections you picked. Anything the script builds at run time (a table name assembled from a variable, for example) cannot be detected, so open each code-mode flow after import and check it.

Quotas

If the import would push the target account over its plan limit, it is blocked before anything is created. An archive with several workspaces is checked as a whole, so you never end up with half of them created and the rest refused. Upgrade the plan or import fewer workspaces.