Understanding Server Sync: Copying Apps and Content Between Servers

Server Sync pushes apps, reports and dashboards from one Yurbi server to another and keeps the copies up to date. Use it to promote work from development to production, distribute a standard set of content to several servers, or move content between servers.

This article is for administrators. Server Sync lives at Settings → Server Sync and needs administrator rights on both servers.

How it works

Server Sync is a push: one source server sends content to one or more destination servers. A background service on the source checks about every five minutes for sync entries that are due and pushes them to the destination over its API, signed in as a user you choose — the sync user. Syncing an item again updates the existing copy on the destination; it does not create a duplicate.

Any two servers work as long as the source can reach the destination over HTTPS. Apps and items are set up separately: sync the app first, then the reports and dashboards that belong to it.

When you would use it

Scenario	How Server Sync helps
Development → QA → production	Build and test on one server, then promote finished content
Same content for several customers	Maintain one report set and push it to each customer's app with the same structure
Tiered or paid content	Deliver additional reports when a customer upgrades
Templates across workspaces	Distribute a standard starter set to new servers
Training and sandbox servers	Refresh a practice server from production content
Moving servers	Carry apps and content to a new server
Regional servers	Keep the same content on servers in different regions
Partner or OEM distribution	Push your content to servers you do not administer day to day
Consolidation	Bring departmental servers into one central server

If one report set should serve many customers from a single server, per-user datasource credentials are usually a better fit than copying the content. Server Sync is the practical choice when the servers or app structures are separate.

What is copied and what is not

Copied	Not copied
App structure: tables, fields, joins, report types	Datasource credentials
Report definitions: fields, criteria, sorting, formatting, visualization	Report and dashboard permissions
Dashboard layout, widgets and the reports they reference	Folder structure on the destination
Report-to-report links	Scheduled deliveries and subscriptions
Pivot and crosstab drilldown targets	Other drilldown types; dashboard filter-view bindings

Two consequences to plan for: a synced app arrives with no datasource credentials and returns no data until you enter them under Settings → Integrations on the destination, and synced content is visible only to the sync user and administrators until you set permissions.

Requirements

Network. The destination's API URL must be reachable over HTTPS from the source; confirm firewalls and routes first. Server Sync cannot be used where no network path exists.

A dedicated sync user on both servers — set up as a service account. Create a user used only for Server Sync on the source and on each destination. Do not reuse a person's account: when that person leaves or changes their password, every sync breaks.

Mark each sync user as a Service account (API integration) in the user editor. The sync service signs in with a stored password every few minutes and cannot answer a two-factor prompt or choose a new password, so without this flag the sync silently stops the moment you turn on Required two-factor, tick Require password change at next login, or force a password change for all users. See Service Accounts for Integrations and Embedding.

Server	The sync user needs
Source	Full access to every app being synced and every folder items are read from. An app the sync user cannot see is skipped without an error.
Destination	Full access to the target app and write access to the target folder.

Give the sync user a long random password and keep it only in the server registration. Account lockout still applies to service accounts, so if you rotate the password, update the registered server entry before the next pass.

Versions. A newer source syncing to an older destination usually works, but keep both servers on the same version where you can.

Target app and folder. The destination must already have an app to receive the structure (a stub is fine — any name, no tables or datasources needed) and a folder to receive items.

Setting up Server Sync

Create the sync user on the source and on each destination, grant the access in the table above, and turn on Service account (API integration) for each.
Prepare the destination. Create the app stub under Settings → Integrations, create a receiving folder (for example Sync Inbox), and confirm the sync user can open both.

Register the servers on the source under Settings → Server Sync → Servers → Create Server. Register your own server once as Source and each remote server as Destination:

Field	What to enter
Server Name	A label
API URL	The server's base address with no trailing slash
Username	The sync user
Type	Source or Destination
PIN	The sync user's password (the field is labelled PIN but there is no separate PIN)

Click Test Connection before saving. When you edit a server later the PIN field is blank, because passwords are never shown; re-enter it or the test fails.

Sync the app from the Apps tab with Create Apps: choose the source app, the destination server, the destination app name (your stub) and a schedule mode (see below). After about five minutes the Status column shows Success when the structure has arrived.
Enter datasource credentials for the synced app on the destination under Settings → Integrations, and confirm a report returns data.
Sync the items from the Items tab with Create Items: pick the reports and dashboards, then the destination server, app, folder and schedule mode. When you select a dashboard, leave include referenced reports on so its widgets have their reports.
Finish on the destination. Move content from the receiving folder to its permanent folders, set permissions, and open each dashboard to confirm it renders.

Schedule modes and timing

The sync service checks for work about every five minutes, so nothing happens instantly.

Once — runs on the next pass after you save, then stops. Use it for deliberate promotions.
Daily — runs again once 24 hours have passed since the last successful sync. Use it for content that changes often.
Sync Now (row action menu) — queues the entry for the next pass. It updates the existing copy on the destination.

The everyday workflow is: edit on the source, then Sync Now on that item's entry.

Changing and removing entries

Changing an entry's destination folder moves the existing copy. An item maps to one folder per destination server.
Deleting an entry stops future syncs; the content already on the destination stays until you remove it there.
There is no pause. To stop syncing, delete the entry; to resume, create it again.
Deleting and re-creating an entry produces a second copy and leaves the first unlinked. This is the way to force a clean re-sync — delete the old copy on the destination afterwards.
Copying synced content on the destination creates a new, unlinked report that no longer receives updates. Move it instead, and let destination administrators know.

Limitations

Area	Detail
Drilldowns	Only pivot and crosstab drilldowns are remapped. Chart hover, calendar and KPI drilldowns keep their source report references and must be reconfigured on the destination.
Dashboard filter views	Filters bound to specific reports keep source references and need rebuilding.
Permissions	Not synced; set them after each first sync.
Datasource credentials	Not synced; enter them after the first app sync.
Folders	All items land in the receiving folder; moving them afterwards does not break the link.
Scheduled deliveries	Not synced; recreate them on the destination.
Deleted destination content	A deleted report is recreated on the next sync. A deleted dashboard is not — delete and re-create its entry.
Advanced Reports	Sync the base report too, or the link points back to the source.
Stored-procedure Advanced Reports	The source app must also be configured on the Apps tab.
Legacy Yurbi v10 apps	Not supported.
Removing a server	Deleting a registered server does not delete its entries; they return if the server is re-registered.

Example: promoting a dashboard from development to production

A dashboard with four reports on the Support Analytics app is ready to move from the development server to production.

On production

Create the user syncuser, mark it as a service account, and give it administrator or full-access rights.
Create an empty Support Analytics app stub under Settings → Integrations.
Create a Sync Inbox folder.
Confirm syncuser can open both.

On development

Create a matching syncuser with access to the Support Analytics app and the dashboard's folder, marked as a service account.
Under Settings → Server Sync → Servers, register development as the Source and production as a Destination, using syncuser and its password. Test the connection.
On the Apps tab, create an entry mapping Support Analytics to the production stub, schedule Once.
After about five minutes, confirm the status shows Success.

Back on production

Enter the database credentials for Support Analytics under Settings → Integrations and confirm a report returns data.

On development

On the Items tab, create an entry for the dashboard with referenced reports included, destination production, app Support Analytics, folder Sync Inbox, schedule Once.

Verify on production

Confirm the five entries (dashboard plus four reports) show Success.
Open the dashboard and confirm every widget renders.
Move the content from Sync Inbox to its permanent folders.
Set permissions for the users who should see it.

From then on, edit on development and click Sync Now on the dashboard's entry; production updates within about five minutes.

Common mistakes

Mistake	Result
Sync user cannot see the app on the source	Nothing happens and no error is shown — the most common cause of a "stuck" entry
Sync user is not a service account	Sync stops when two-factor becomes required or a password change is forced
No target app stub on the destination	App sync never succeeds
No target folder	Item sync fails
Credentials not entered after the app sync	Reports error or return no data
Dashboard synced without its reports	Empty or broken widgets
Expecting an instant sync	Nothing for about five minutes
Deleting an entry to remove content	Content stays on the destination
Copying synced content on the destination	The copy stops updating
Editing a server without re-entering the PIN	"Connection failed"
Trailing slash on the API URL	Connection test fails
Mismatched versions	Unpredictable results

Troubleshooting

An entry shows no status. The sync user almost certainly cannot see the app or folder on the source. Sign in as the sync user and check.

Connection test fails. Check the API URL has no trailing slash, the password is correct and freshly entered, the destination is reachable over HTTPS, and the sync user is not locked, disabled or flagged for a password change on the destination.

Syncs stopped after a security change. If you recently turned on Required two-factor or forced a password change, the sync user on the destination is being prompted and cannot answer. Mark it as a service account; the next pass completes. See Service Accounts for Integrations and Embedding.

The app syncs but its reports fail. Datasource credentials are missing on the destination. Enter them under Settings → Integrations.

Dashboard widgets are empty. The referenced reports were not synced, or went to a different app. Check each report has its own entry pointing at the same destination app.

Content appears twice. An entry was deleted and re-created. Delete the older copy on the destination.

Getting help

Contact the Yurbi team with the source and destination server names, the sync entry involved, and the status shown on the Apps or Items tab.