How configuration reaches the desktop
The pull-sync loop, what "centrally managed" changes, and how to tell whether a change has landed.
Everything an admin edits in the portal — playbooks, shared integrations, AI provider credentials, the spend cap, the member and team directory — is one configuration payload. Each desktop install pulls that payload and applies it locally.
The loop
- An admin saves a change in the portal.
- The organization's configuration revision counter increments.
- Each connected desktop polls (roughly every 15 minutes, or immediately if someone hits refresh in the app).
- If the revision is unchanged, the desktop does nothing. If it moved, the whole payload is applied: rows are written into local SQLite and secrets are re-encrypted under that machine's own key.
- The desktop reports back what actually happened when it tried to start each integration — running, degraded, the error text, the tool count.
That last step is why the portal's Integrations page shows health that is last reported rather than live. The portal never test-connects anything; it has no long-lived process to do it from. Saving in the portal validates the shape of a config, not whether the credential works.
Directory changes ride the same counter
Members and teams are part of the config payload, not a separate 24-hour roster refresh, and they are always applied before the configuration that references them. A new team therefore exists locally before the team-scoped playbook that points at it.
Centrally managed mode
Once an install has pulled its organization's configuration even once, it is centrally managed. From that point:
- The desktop's own admin pages for playbooks, integrations, AI providers and organization settings go read-only. A local write is refused outright rather than being accepted and then silently overwritten by the next sync.
- The portal is the only place those things change.
- Tickets, the Console, history and usage stay entirely local and are unaffected.
Before that first sync — a freshly activated install whose organization has nothing configured yet — the local admin pages are still editable. They lock as soon as the first payload lands.
"I changed it and nothing happened"
Work down this list:
- Give it 15 minutes, or open the desktop app and refresh. Sync is a poll, not a push.
- Check the member is actually signed in to the org on that machine. An install that never connected has nothing to pull.
- Check the Integrations page in the portal for the last reported status. If a shared data source is degraded, the desktop received the config and failed to start it — the error text there is the real problem, and it is usually a credential that is wrong, expired, or unreachable from that machine's network.
- Check the Audit log. If your change is not there, it did not save.
What never syncs
Deliberately, and not as a gap to be closed:
- Usage and spend telemetry stay on the desktop. The portal sets the monthly cap; the desktop meters against it and knows the month-to-date figure.
- Playbook report schedules are configured and run on the desktop.
- Playbook revision history is kept locally by the desktop. The portal's record of who changed what is the Audit log.