Some backup or migration plugins show an admin notice about database tables that are outside the default WordPress table prefix or not included in backups by default. FleekDash users often see this for tables whose names contain fleekdash_integration_registry.
This notice is usually informational, not an error. FleekDash is not broken and your site is not misconfigured.
What you might see
Backup and database tools use different wording, but the pattern is the same:
A banner or email saying one or more tables are not captured in backups
A table name such as {prefix}fleekdash_integration_registry
A prompt to review data preferences, opt in, or exclude certain tables
Examples of plugins that may show this kind of notice:
Backup plugins that filter tables by prefix
Staging or clone tools that create duplicate tables with their own prefix
Database scanners that list "non-WordPress" tables
FleekDash does not ship or require a specific backup plugin. Any tool that classifies tables by prefix can show the same message.
What these tables are
FleekDash stores third-party integration metadata in standard WordPress database tables. They always use your site's $table_prefix from wp-config.php (often wp_, but it can be custom).
Common FleekDash integration tables:
| Table suffix | Purpose |
fleekdash_integration_registry | Registered integrations (id, name, status, manifest) |
fleekdash_integration_routes | Custom #/app/... routes for integration UIs |
fleekdash_integration_settings | Per-integration settings stored in the database |
Example full names:
wp_fleekdash_integration_registry (default prefix)
myclient_fleekdash_integration_registry (custom prefix)
These tables hold configuration and metadata, not your posts, orders, media files, or customer records.
Built-in vs external integrations
FleekDash uses two layers:
Built-in integrations (for example OpenAI inside FleekDash) live in plugin files and WordPress options. They do not depend on the registry table.
External integrations (separate WordPress plugins that register with FleekDash) write metadata to the registry tables and appear in the Integrations Hub.
If registry data is missing after a restore, FleekDash can often rebuild entries when those plugins register again. Opting the tables into backup avoids extra reconfiguration work.
Why backup tools flag them
Most backup plugins include core WordPress tables automatically. When they find a table name that does not match the prefix they expect, they warn you that the table will not be backed up unless you opt in.
That is a safety feature of the backup tool. It helps avoid backing up tables from another application on a shared database.
Common reasons the flagged name looks unusual:
Your site uses a custom $table_prefix and the backup tool only recognizes wp_
A staging or clone created a duplicate table with a tool-specific prefix (names often start with segments like stg_, staging_, or similar)
The scanner lists old leftover tables from a previous migration
Important: FleekDash creates tables with your WordPress prefix. It does not create random tables outside WordPress conventions.
Do you need to back these tables up?
Short answer: No action is required for day-to-day use. Optional backup is recommended if you want integration settings restored exactly after disaster recovery.
| Your goal | What to do |
Site keeps working normally | No action. Dismiss or ignore the notice if you prefer. |
Flagged name looks like a staging or clone artifact | Safe to dismiss. It is often not your live production table. |
You want full restore fidelity for the Integrations Hub | Optionally opt in in your backup plugin's data or table preferences. Include {your_prefix}fleekdash_integration_* tables. |
You are unsure which table is live | Compare the name in the notice with $table_prefix in wp-config.php. The live table should start with that exact prefix. |
What happens if they are not backed up?
FleekDash admin, posts, and WooCommerce data are unaffected
External integrations may need to register again or be reconfigured in the Integrations Hub after a full database restore
Built-in integrations continue to work from files and options
How to opt in (generic steps)
Exact labels vary by plugin. Look for settings named like:
Data preferences or Table selection
Include custom tables or Non-core tables
Database backup scope
Then:
Open your backup plugin's database or tables settings.
Find tables ending in fleekdash_integration_registry, fleekdash_integration_routes, and fleekdash_integration_settings.
Include tables whose prefix matches your live $table_prefix.
Exclude or ignore tables that clearly belong to staging or clone tools (different prefix than production).
If your host runs backups for you, send them the table names above and ask to include tables that match your production prefix.
Quick answers for clients
You can share this summary:
The backup notice about fleekdash_integration_registry is normal. It means your backup tool is telling you that some FleekDash integration metadata tables are not in the default backup set. That is not a FleekDash error. You do not need to panic. Include those tables in backup preferences only if you want integration hub settings restored exactly after a full database restore. Otherwise you can dismiss the notice.
Related documentation
Integrations Hub: Discover, activate, and configure integrations in FleekDash.
Integrations Hub tips: Empty list, activation issues, and plugin errors.
Build FleekDash integrations: Developer guide for plugins that register with the Registry.
Still unsure?
When contacting support, include:
The exact table name from the backup notice
Your $table_prefix from wp-config.php (first line is enough, no passwords)
The backup or staging plugin name and version
We can confirm whether the flagged table is your live registry or a staging artifact.