SoxDesk Admin Guide

Everything an administrator needs: users and roles, email sign-in (SMTP), the shared data store, backups and restore, licensing, and advanced overrides.

Admin functions live on the Admin page and are only visible to users with the admin role.

1. Users and roles

Application roles (Admin → Users)

• Add a user with full name + email. The email is the sign-in identity — a user without an email cannot sign in.
• Deactivate instead of deleting: deactivated users keep their history (sign-offs, activity log) but can't sign in and don't appear in assignment lists.
• The server blocks removing or deactivating the last active admin — you can't lock yourself out of administration.

First-run bootstrap

On a brand-new data store, SoxDesk shows a bootstrap screen that creates the initial admin. It is guarded server-side: it only works while no active admin with an email exists, so it can't be used to add accounts later.

Audit roles (Admin → Team)

Per audit, members are added as lead, tester, or reviewer. Leads (or admins) manage the team, assign testers/reviewers on tests, control leverage links, run RCM imports, and can force-release workpaper checkouts. The workflow enforces that a test's reviewer differs from its preparer.

2. Sign-in and SMTP

SoxDesk offers three sign-in modes; choose per deployment under Admin → Login method:

• Local passwords — scrypt-hashed with a per-user salt, minimum 8 characters, fully offline (no mail server required). Users change their own password once signed in; when an admin first enables password mode, accounts without a password set one at next sign-in. There's no self-service reset — an admin resets a password from the Users table.
• One-time email codes (default) — a 6-digit code sent to the user's email: codes expire after 10 minutes, allow 5 attempts, are single-use, have a 30-second resend throttle, and are stored hashed in the database.
• Corporate directory (LDAP / Active Directory) — users sign in with their existing AD credentials, verified by binding to your directory. Configure it under Admin → Directory (LDAP / Active Directory): enter the server URL (ldaps://… recommended), optionally a service account for search-then-bind (leave blank to bind directly with the login email as the AD userPrincipalName), the search base, and the user filter. Use the Test login button with a real account before switching the login method. Each directory user must already have a SoxDesk account with a matching email — SoxDesk verifies the password against the directory but never stores it, and controls who has access.

Any mode creates a 7-day session on success (httpOnly cookie, hashed token, stored in the shared database — so sessions roam between installs pointing at the same store).

Configuring SMTP (Admin → Email sign-in (SMTP))

Enter your mail server's host, port, TLS setting, optional username/password, and a From address (e.g. soxdesk@yourco.com). Save, then use Send test email to confirm delivery. All mail goes through your own SMTP server — SoxDesk has no mail service of its own and makes no other outbound connections.

Typical setups: an internal Exchange/relay endpoint (often port 25, no auth, no TLS inside the LAN) or an authenticated submission endpoint (port 587, TLS).

Dev fallback (before SMTP is configured)

Until SMTP is configured, SoxDesk still works:

• login codes are printed in the server window log, and
• admins see a Pending login codes table on the Admin page (user, code, expiry).

This is intended for evaluation and initial setup. Once SMTP is saved, codes are emailed and the pending-codes table disappears.

3. The data store

The data store is one folder containing everything:

<store>\
  soxdesk.db      ← the audit database (SQLite, single file)
  attachments\    ← evidence files (stored under randomized names)
  backups\        ← automatic rotating backups

Pointing at a network share (Admin → Data store)

Enter the shared folder path (e.g. \\fileserver\audit\SoxDesk-Store) and click Save, then restart SoxDesk — the setting takes effect on the next start. Every team member points their own install at the same folder; that is the entire multi-user deployment.

Notes:

• Changing the path does not move existing data. To migrate, stop SoxDesk, copy the contents of the old store folder into the new location, set the new path, restart.
• The database deliberately runs in SQLite DELETE journal mode (not WAL) with a 5-second busy timeout, because WAL does not work reliably on SMB network shares. This is by design — don't "tune" it back to WAL.
• The share must be reachable while people work. Offline replica/sync is on the roadmap.
• Concurrency (checkout atomicity, parallel writes from multiple installs) is exercised by an automated stress suite on every release.
• Upgrading SoxDesk never touches the store's location: replace the app folder, start, and the schema migrates automatically. (Stores created under the app's previous internal name are migrated automatically too.)

4. Backups and restore

What happens automatically

• On startup and every 6 hours, SoxDesk copies the database using SQLite's online backup API — safe while users are actively working.
• Backups are written to <store>\backups\ as soxdesk-<timestamp>.db.
• The 14 most recent backups are kept; older ones are deleted automatically.

Because the store is plain files, your normal file-share backup (nightly tape/snapshot) covers SoxDesk with no special handling. Note that the automatic backups cover the database only — evidence files in attachments\ change rarely and are best covered by your file-share backup.

Restoring from a backup

1. Stop every SoxDesk instance pointing at the store (close each "SoxDesk Server" window).
2. In <store>\backups\, pick the backup to restore (timestamps are in the filename).
3. Safety copy: rename the current <store>\soxdesk.db to soxdesk.db.broken (don't delete it yet).
4. Copy the chosen soxdesk-<timestamp>.db into <store>\ and rename it soxdesk.db.
5. Start SoxDesk and verify. You lose at most the work since that backup was taken; evidence files in attachments\ are unaffected (a restored database may reference attachments uploaded after the backup — those files remain on disk).

5. Licensing (Admin → License)

• Trial: full-featured for 60 days from first run (the install date is recorded on first boot and shown on the License card).
• Expired: the app becomes read-only — sign-in, viewing, and all exports keep working. No data is ever locked away.
• Applying a key: paste the full key into the License card and click Apply license. Validation is an offline Ed25519 signature check — no internet connection is used, ever.
• Updates coverage: your license covers every SoxDesk build released on or before your license's updates-until date (both dates are shown on the License card). A newer build than your coverage runs under trial rules and tells you so — either renew for a new key, or keep running your last covered build indefinitely.
• The license is stored in the shared database, so licensing the store once covers every install pointing at it.

6. Advanced: host and port overrides

Defaults: SoxDesk listens on 127.0.0.1:5179 — reachable only from the machine it runs on. Two environment variables override this (set them before launching, e.g. in a copy of SoxDesk.cmd):

Security note: the listener speaks plain HTTP with no TLS. If you set AF_HOST to anything other than localhost, sessions and data cross the LAN unencrypted. The recommended patterns are (a) keep the default and give each user their own install, or (b) front a single shared instance with a TLS-terminating reverse proxy (IIS/nginx/Caddy) and keep SoxDesk itself bound to 127.0.0.1. See the Security Overview for the full picture.

7. Roll-forward and periodic tasks

• New period: Admin → New audit → Roll forward clones the current audit — structure, team, controls, tests, linkage, and workpaper content carry over; statuses, sign-offs, findings, and evidence start fresh.
• Archive: at period end, use the Report page's Export archive (zip) for a retention package (workpapers with sign-off stamps, evidence, report/findings/activity CSVs), and keep a copy of the whole store folder per your retention policy.

Questions or problems: support@soxdesk.com (async email, 48-hour response).