Understanding Server Sync: Copying Apps and Content Between Servers

Server Sync copies apps, reports, and dashboards from one DashboardFox server to another, and keeps the copies updated as the originals change. This guide explains what it does, what it doesn't do, how to set it up, and the limitations worth knowing before you build a process around it.

It's written for administrators. Server Sync lives under Settings → Server Sync and requires admin rights on both servers involved.

Availability: Server Sync is included in all DashboardFox on-premise deployments. On DashboardFox Cloud, it's available on the Scale and Enterprise tiers.

What Server Sync Does

Server Sync is a push mechanism. You nominate one server as the source, register one or more destination servers, and then define what should be copied:

Apps — the app definition itself: tables, fields, joins, report types. The structure your reports are built on.
Items — individual reports and dashboards from your Documents library.

A background service on the source server checks the sync configuration roughly every five minutes. When something is due, it logs into the destination over its API and pushes the content across.

The important word is sync, not copy. Once an item is linked, editing it on the source and triggering another sync updates the existing copy on the destination rather than creating a second one. That link is what makes Server Sync useful for an ongoing promotion process rather than a one-time move.

A few structural facts worth internalizing:

One source, many destinations. A single server can push the same content to as many destinations as you like — useful for distributing standard content across client or departmental instances.
Direction doesn't matter. On-premise to cloud, cloud to cloud, cloud to on-premise — all supported. What matters is network reachability, covered below.
Apps and items are configured separately. Syncing an app doesn't bring its reports. Syncing a report doesn't create the app it depends on. You do both, in that order.

When You'd Use It

Scenario	How Server Sync fits
Development promotion	Build and test in a dev server, promote to QA, then to production. Each promotion is a sync rather than a manual rebuild, and re-syncing pushes updates to content already promoted.
Cross-app content reuse	You have separate apps for Customer A and Customer B with identical structure. Build the report set once against Customer A's app, then sync those reports and point them at Customer B's app — including on the same server.
Tiered or paid content	A customer upgrades their plan and you push them the dashboards that come with the new tier.
Multi-workspace template distribution	You maintain a master workspace with canonical dashboards; each new client workspace receives the same content rather than having it rebuilt by hand.
Training and sandbox environments	Push production content to a training server so users practice against real reports without touching live data.
Platform migration	Moving from on-premise to cloud (or back). Content moves first, users cut over afterward.
Regional separation	Same content, separate instances, data staying in its region.
Partner or OEM distribution	You build the analytics; your partner's server receives it.
Consolidating scattered deployments	Several departmental servers feeding content into one central reporting instance.

A note on the cross-app use case

Copying a report set from one customer's app to another is a common request, and Server Sync handles the copying. But if your goal is one set of reports serving many customers with each seeing only their own data, the better tool is dynamic credentials rather than duplication — a single app whose datasource credentials resolve per user at runtime, so one report serves everyone.

On DashboardFox Cloud, that capability requires the Scale or Enterprise tier. If you're on a lower tier, or your customer apps genuinely differ in structure, Server Sync's duplicate-and-relink approach is the practical alternative.

What Gets Synced and What Doesn't

This is the section most worth reading twice. Server Sync copies definitions, not the surrounding configuration.

Synced	Not synced
App structure — tables, fields, joins, report types	Datasource connection credentials
Report definitions — fields, criteria, sorting, formatting, visualization settings	Report and dashboard permissions
Dashboard layout, widgets, and their report links	Folder structure on the destination
Report-to-report join and link relationships	Scheduled deliveries and subscriptions
Pivot and crosstab drilldown targets	Other drilldown types (see Limitations)
	Dashboard filter view bindings (see Limitations)

Datasource credentials are the one that catches people out. A synced app arrives on the destination with its full structure and an empty credential set. It will not return data until you open Settings → Integrations on the destination and edit the app registration to supply the database connection details. This is deliberate — your production database credentials shouldn't travel automatically to a dev server.

Permissions don't travel either. Content lands accessible to the sync user and to administrators. Granting access to the people who actually need it is a step you perform on the destination.

Requirements and Prerequisites

Work through these before you configure anything. Most Server Sync problems trace back to one of them.

Network connectivity

The source server makes API calls to the destination server. That means:

The destination's API URL must be reachable from the source server over HTTPS.
If either server sits behind a firewall, the relevant path must be open.
For cloud-to-cloud, both instances are publicly reachable and this is automatic. For anything involving on-premise, confirm the route before you start.

If you need to move content between servers with no network path between them, Server Sync isn't the answer — an offline export/import capability is in development, though that will be a one-time transfer rather than an ongoing sync.

A dedicated sync user on both servers

Create a user account used only for Server Sync, on the source and on each destination. Don't reuse a person's account — when they leave, your syncs break.

That account's permissions are the single most common cause of a sync that appears configured correctly and silently does nothing:

On the source: full access to every app being synced and every folder items are read from. If the sync user can't see an app, the sync service can't see it either, and the app will be skipped with no error.
On the destination: full access to the target app and write access to the target folder.

Version alignment

A newer source can generally sync to an older destination, but we recommend keeping both servers on the same version. Version differences are where unexpected behavior shows up.

The target app stub must already exist

Server Sync updates an existing app on the destination; it does not create one. Before syncing an app, create a placeholder app on the destination — the name can differ from the source, and it doesn't need tables or datasources configured. The sync overwrites its structure.

The target folder must already exist

Same principle for content. Create the destination folder before syncing items to it.

The Setup Workflow

1. Create the sync user on both servers

Create the dedicated account on the source and on each destination, and grant the permissions described above. Do this first — most later problems are permission problems.

2. Prepare the destination

On each destination server:

Create the target app stub under Settings → Integrations.
Create the folder that will receive synced content. A dedicated folder such as Sync Inbox works well — content lands there and you move it afterward.
Confirm the sync user has full access to both.

3. Register your servers

On the source server, go to Settings → Server Sync → Servers and click Create Server. Register:

The source server — your own server, with Type set to Source. Only one source server is supported.
Each destination server, with Type set to Destination.

For each entry:

Field	What to enter
Server Name	A label for your own reference — Production, Client A, QA.
API URL	The server's base URL, e.g. `https://yourcompany.dashboardfox.app`. No trailing slash.
Username	The sync user's login.
Type	Source or Destination.
PIN	The sync user's password. The field is labeled PIN, but there's no separate PIN to generate — this is the account password.

Click Test Connection before saving. It logs in with the credentials you supplied and reports back. Saving without a successful test means the sync service will fail later with no obvious cause.

When editing a server, you must re-enter the PIN. Passwords are never returned to the browser, so the field is always blank when you reopen a server. Leaving it empty and saving will fail the connection test.

4. Sync your apps

Go to the Apps tab and click Create Apps:

App Source — the app on your source server.
Destination Server — where it's going.
Destination App Name — the stub you created in step 2.
Schedule Mode — Once or Daily (see below).

Save, then wait for the next sync pass. The Apps list shows Last Sync and Status columns; a status of Success means the app structure landed on the destination.

Sync apps before items. Reports depend on their app's structure existing on the destination.

5. Configure the destination app's credentials

Once the app has synced, open Settings → Integrations on the destination and edit the app registration to supply the datasource connection details. Until you do, the app has structure but no data, and reports built on it will fail.

6. Sync your items

Go to the Items tab and click Create Items. Select the reports and dashboards you want, choose the destination server, destination app, and destination folder, and set the schedule mode.

If you're syncing dashboards, include the reports they contain. A dashboard's widgets reference specific reports. If those reports aren't also synced, the widgets on the destination will point at reports that don't exist there. The Items form can identify a dashboard's reports and include them for you — leave that option enabled unless you have a reason not to.

7. Finish on the destination

After items sync successfully:

Move content from the sync folder into your real folder structure.
Set permissions so the intended users can see it.
Verify dashboards render — widgets should display data, not errors.

Schedule Modes and Timing

The sync service checks for work approximately every five minutes. Nothing happens instantly; everything queues for the next pass.

Mode	Behavior
Once	Syncs on the next pass after you save, then stops. The normal choice for a promotion — you push a change deliberately, not on a timer.
Daily	Syncs when 24 hours have elapsed since the last successful sync. Use when the source changes regularly and you want the destination to keep up without manual steps.

Re-running a sync

For an entry already showing Success, use Sync Now from the row's actions menu. It clears the sync history so the item runs again on the next pass — within about five minutes.

Sync Now updates the existing copy on the destination. It does not create a second one.

Pushing an update after editing content

Edit the report or dashboard on the source, then use Sync Now on its sync entry. The destination copy is overwritten with the new definition. This is the everyday workflow once your sync entries are established.

Changing and Removing Sync Entries

Changing the destination folder

Re-adding an item with a different destination folder moves the existing copy rather than creating a second one. There's no way to sync one report into two folders on the same destination — the sync link is one-to-one per destination server.

Deleting a sync entry

Deleting an entry stops future syncs. It does not delete the content on the destination. That copy remains and must be removed manually if you don't want it.

There's also no pause. If you want to stop syncing something temporarily, delete the entry and re-create it later — bearing in mind the next point.

Deleting and re-adding creates a second copy

Once you delete a sync entry, the link to the destination copy is gone. Re-adding the same item creates a new copy on the destination; the original stays behind, no longer tracked by anything.

That's the supported way to force a clean re-sync from scratch — just be aware you'll have two copies and should delete the old one.

Copying content on the destination breaks the link

If someone copies a synced report on the destination, the copy gets a new report ID and is not connected to the sync. The original keeps receiving updates; the copy silently doesn't. Move synced content rather than copying it, and tell your destination administrators the same.

Known Limitations

Limitation	What it means in practice
Drilldown targets	Only pivot and crosstab drilldowns are remapped to the destination copies. Chart hover targets, calendar drill targets, and KPI card drilldowns arrive still pointing at the source server's report IDs. Reconfigure them on the destination.
Dashboard filter views	Filters that bind to specific reports keep their source report IDs. Dashboards with saved filter views need those filters rebuilt on the destination.
Permissions	Not synced. Set them on the destination after each sync.
Datasource credentials	Not synced. Configure them on the destination app after the first app sync.
Folder structure	Every item in a sync configuration lands in one destination folder. Reorganize on the destination afterward — moving content doesn't break the sync link.
Scheduled deliveries	Report schedules and subscriptions don't travel. Recreate them on the destination if needed.
Deleted destination dashboards	If a synced report is deleted on the destination, the next sync recreates it. Dashboards don't recover this way — delete the sync entry and re-create it.
Advanced Reports	An Advanced Report's underlying base report must also be synced, or its link stays pointed at the source server. Include both.
Stored Procedure Advanced Reports	These additionally require the app they draw from to be configured on the Apps tab, or their stored-procedure field references won't resolve on the destination.
Legacy Yurbi v10 apps	Apps of type Yurbi v10 aren't supported by Server Sync.
No pause	Delete the entry to stop syncing; there's no temporary disable.
Removing a server	Deleting a registered server doesn't remove its app and item entries. If you re-register a server later, previously configured entries can reappear.

A Worked Example: Promoting a Dashboard from Dev to Production

Your dev server has a Support Analytics app and a dashboard built on it with four reports. You want it on production.

On production:

Create a sync user, sync, with a strong password.
Under Settings → Integrations, create an app named Support Analytics. Leave it empty.
In Documents, create a folder named Sync Inbox.
Grant the sync user full access to the app and the folder.

On dev:

Create the same sync user, with full access to the Support Analytics app and the folder holding the dashboard and its reports.
Go to Settings → Server Sync → Servers. Add your dev server as Source and production as Destination, using the sync user credentials. Click Test Connection on the destination — confirm it succeeds.
On the Apps tab, create a mapping: source app Support Analytics → destination Support Analytics, schedule Once. Save.
Wait about five minutes. Confirm the Apps list shows Success.

On production again:

Go to Settings → Integrations and edit the Support Analytics app registration. Enter the production database credentials. Verify the app returns data.

On dev:

On the Items tab, click Create Items. Select the dashboard, leave the include-referenced-reports option enabled so its four reports come along, choose production as the destination server, Support Analytics as the destination app, Sync Inbox as the folder, and Once as the schedule. Save.
Wait for the next pass. Confirm all five entries show Success.

On production, finally:

Open the dashboard and confirm every widget renders data.
Move the dashboard and its reports from Sync Inbox into their permanent folders.
Set permissions for your users.

When you later change a report on dev, use Sync Now on its Items entry. Within five minutes, the production copy updates in place.

Common Mistakes and Gotchas

Mistake	Symptom	Fix
Sync user lacks permission to the source app	Sync runs, status never changes, nothing appears on the destination	Grant the sync user full access to the app on the source server. This is the most common cause of a silent no-op.
Target app stub doesn't exist	App sync never succeeds	Create the app under Settings → Integrations on the destination before configuring the mapping.
Target folder doesn't exist	Item sync fails	Create the folder on the destination first.
Datasource credentials not configured after app sync	App structure is there, reports return errors or no data	Edit the app registration under Settings → Integrations on the destination and enter connection details.
Dashboard synced without its reports	Dashboard appears but widgets are empty or broken	Re-sync with the include-referenced-reports option enabled, or add each report as its own item.
Expecting an immediate sync	Nothing happens right after saving	The service checks roughly every five minutes. Wait a pass.
Deleting a sync entry to remove content	Entry disappears, content remains on the destination	Delete the content manually on the destination.
Copying synced content on the destination	The copy stops receiving updates	Move synced content instead of copying it.
Editing a server without re-entering the PIN	"Connection failed" on save	Re-enter the sync user's password. It's never returned to the browser.
Trailing slash on the API URL	Connection test fails	Enter the base URL with no trailing slash.
Source and destination on different versions	Unpredictable results	Keep both servers on the same version.

Troubleshooting

A sync entry shows no status at all. The service hasn't run yet, or it ran and skipped the entry. The most likely cause is the sync user lacking access to the app on the source server. Verify by logging into the source as the sync user and confirming the app and content are visible.

The connection test fails. Check the API URL is correct and has no trailing slash; confirm the sync user's password; confirm the destination is reachable from the source over HTTPS; confirm the user isn't locked out on the destination.

An app syncs but reports fail on the destination. Datasource credentials aren't configured. Edit the app registration under Settings → Integrations on the destination.

A dashboard's widgets are empty. Its reports weren't synced, or were synced to a different destination app. Confirm each referenced report has its own entry on the Items tab.

Content appears twice on the destination. Usually a sync entry was deleted and re-added. Delete the older copy manually.

Getting Help

For issues you can't resolve, contact team@dashboardfox.com with your source and destination server names, the sync entry involved, and the status shown on the Apps or Items tab.