The Settings Folder¶
Inside the local install at C:\Users\<username>\AppData\Local\Leahy\Pulse Dashboard 5\ there's a Settings\ subfolder that gets special treatment from the launcher. This page explains what's in it, what the launcher does with it, and why.
What's in Settings\¶
The Settings\ folder holds the SQL connection configuration that tells this particular installation of Pulse Dashboard which database to connect to. That's it. It's a small set of files that say things like "connect to SQL Server X, database Y, with these credentials."
It does not hold: - User preferences, layouts, or saved views (those live in the database itself, so they follow the user across machines). - Application settings or feature toggles (also in the database). - Recently-opened files, window positions, etc. (also in the database).
If a user logs in from a different machine and sees their preferences come back, that's because the database is the source of truth — not because anything is being copied between machines.
How the launcher treats Settings\¶
The launcher applies a "populate-once, then sacred" rule:
| Scenario | Launcher behavior |
|---|---|
Settings\ doesn't exist locally yet |
First-launch population from the server is allowed, so the user has a starting point. |
Settings\ already has a file locally |
The launcher will never overwrite it from the server, even if the server's copy is newer. |
| The server doesn't have a file that exists locally | The launcher will never delete it during cleanup. |
In practice this means: the first time a user runs the launcher on a new machine, whatever connection-settings files the server is providing get copied down as a starting template. From that point on, the local copy belongs to that machine. The user can edit it, the developer can ship a different one to the server share, and they will never overwrite each other.
Why this design¶
The two halves of the design — populate from the server and never overwrite afterward — each solve a different problem.
Why ship Settings on the server in the first place: so first-time users don't have to configure connection settings by hand. When IT deploys a new copy of Pulse Dashboard to a user's machine, the user can run the launcher and immediately have a working connection to the right database. The server's copy of Settings\ acts as the default starting point — sensible defaults already configured, ready to use.
Why never overwrite afterward: a user (or IT, or the dashboard application itself) may need to adjust those settings after the fact — pointing to a different SQL server, switching credentials, etc. If the launcher overwrote Settings\ on every sync, those local adjustments would be lost on the next launch.
The populate-once-then-sacred rule gives both behaviors: a turnkey first-run experience, plus full local control after that.
What the launcher logs¶
Every sync logs the Settings exemption explicitly so it's clear what's happening:
[INFO ] Cleanup exemption: contents of 'Settings' folder preserved.
This appears once per sync, regardless of how many files are in Settings\. The launcher doesn't enumerate the individual files inside — it just notes that the whole folder is off-limits.
You'll also see this on the first launch after a fresh install:
[INFO ] Copied C:\Users\...\Pulse Dashboard 5\Settings\connection.config
That's the populate-once population in action. The next launch on that same machine will instead show:
[INFO ] Cleanup exemption: contents of 'Settings' folder preserved.
with no "Copied" line for any Settings file, because the local copies now exist and are protected.
Implications for IT and support¶
A user's Settings\ folder is theirs once it's been populated. The launcher will not auto-repair, replace, or update its contents. If Settings\ has become corrupt, or if you specifically want the server's default connection settings to be re-applied, run the launcher with /clean. This wipes the entire local install, Settings\ included, and forces a fresh populate from the server on the next launch.