# How configuration reaches the desktop

> The pull-sync loop, what "centrally managed" changes, and how to tell whether a change has landed.

Source: https://triagic.com/docs/concepts/config-sync

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 [#the-loop]

1. An admin saves a change in the portal.
2. The organization's configuration revision counter increments.
3. Each connected desktop polls (roughly every **15 minutes**, or immediately if
   someone hits refresh in the app).
4. If the revision is unchanged, the desktop does nothing. If it moved, the whole
   payload is applied: the configuration is stored locally and secrets are re-encrypted
   under that machine's own key.
5. 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.

> **Note:** 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 [#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" [#i-changed-it-and-nothing-happened]

Work down this list:

1. **Give it 15 minutes**, or open the desktop app and refresh. Sync is a poll, not a
   push.
2. **Check the member is actually signed in to the org** on that machine. An install
   that never connected has nothing to pull.
3. **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, usually a credential that is wrong,
   expired, or unreachable from that machine's network.
4. **Check the Audit log.** If your change is not there, it did not save.

## What never syncs [#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](/docs/admin/audit).