Service accounts — keeping integrations, embeds and Server Sync running
If anything signs in to DashboardFox without a person typing a password, it needs to be a service account. Four minutes now saves an outage the day you turn on Required two-factor.
By the end of this lesson
- A list of every account on your site that signs in automatically
- Each of them marked as a service account, showing the Service pill on the Users list
- The one rule — one account, one owner — and why mixing breaks embeds
You'll need
- Login security — this lesson is the step before making two-factor Required
- Admin role
Background
A service account is a DashboardFox user that belongs to a system, not a person. It signs in with a stored password and nobody is there to type a two-factor code or choose a new password. The Service account (API integration) switch in the user editor tells DashboardFox to never interrupt it with those steps.
| A service account skips | It does not skip |
|---|---|
| The two-factor prompt, even in Required mode The two-factor setup screen Require password change at next login |
Lockout after five wrong passwords Password rules when its password is set The Disabled switch Groups, app roles and row-level security |
Which accounts
- Embedding. The account your application signs in with to show dashboards or reports to your end users.
- Server Sync. The sync user you created on the destination server — the service signs in as it every few minutes.
- API integrations and scripts that use a stored username and password.
- Scheduled exports that run under their own DashboardFox login.
An account your application signs in with should not also be an account a person manages. The moment that person enrolls in two-factor or changes their own password, your application can no longer sign in as them — and the embed goes dark.
Either the person owns the account and signs in directly, or your system owns it and it's a service account. Give integrations their own users; never reuse a colleague's.
Each service account sign-in that skipped two-factor is written to the Audit Log, so the bypass is visible rather than silent.
Not sure whether an account counts as a service account? Email [email protected] with what signs in as it. Same business day reply.
Before you start
- Admin role. The switch is in the user editor under Settings → Security → Users.
- Your list of automated sign-ins. Ask whoever built your embed or integration which DashboardFox login it uses. Check Settings → Server Sync → Servers for the sync username if you use Server Sync.
- A plan for the password. A service account's password is its only protection. Use a long random one (32+ characters) stored in your integration's secret store, and rotate it on your own schedule by updating the integration first, then the user.
Do it
-
Open the account
Settings → Security → Users. Find the integration's user and click Edit. If the integration is still using a person's login, create a new user for it now instead — name it for what it does (
svc-embed,svc-sync) and give it only the app roles and group memberships it needs. -
Turn on the switch
Scroll to Additional Options and turn on Service account (API integration). Click Save & Apply.
Two rules you'll run into: you can't flag your own account, and the built-in
adminaccount can only be flagged while signed in asadmin. Don't useadminfor integrations in the first place — it's your recovery account. -
Check the list
Back on the Users list, the row shows a Service pill. Repeat for each account on your list. If the integration had already been failing after a two-factor change, it starts working again at its next sign-in with nothing else to do.
You have a working connection. Every automated sign-in is flagged. Below is how to keep it that way.
Make it real
Three practices for accounts nobody logs in to.
One account per integration
DashboardFox keeps one session per user, so two systems sharing an account sign each other out. Your embed, your sync and your nightly export each get their own user. It also makes the Audit Log readable — you can see which system did what.
Rotate on your schedule, not by force
Never tick Require password change at next login on a service account (it's ignored anyway) and don't rely on a forced change to rotate it. Set the new password in the user editor, update the integration, done. If you rotate the integration first and forget the user, five wrong attempts lock the account for 5 minutes — the Locked pill on the Users list is the tell.
Retire with Disable, not Delete
When an integration is decommissioned, turn on Account disabled rather than deleting the user. Nothing can sign in, and the audit history stays intact. Re-enable it if the integration comes back.
If you're building the integration yourself, the developer guide covers the API side — how to set the flag programmatically and what the sign-in response looks like when an account isn't a service account.
If you're stuck
The two ways this goes wrong.
The embed worked yesterday and shows a blank frame today
Most likely two-factor was made Required, or someone ticked a forced password change, on the account the embed signs in with. Open that user, turn on Service account (API integration), save. If the user is a real person's account, that's the underlying problem — create a dedicated user for the embed.
Server Sync entries show no status after a security change
Check the sync user on the destination server: it should be a service account, not disabled, not locked. Then edit the registered server entry on the source and re-enter the password — it isn't shown when editing and a blank one fails the connection test.
None of these match my situation
Email [email protected] with the account name and what signs in as it.
