Settings: Application
The application's status and name, how long one session may run, and the resets customers may do on their own.
Open it now:Settings, Application
Application status
The switch on this page is a kill switch for the whole application. Disabled, every sign-in is refused with the Application disabled message, with no new build and no waiting, and every session already running is ended at its next heartbeat and logged as Application disabled by owner (maintenance). Enable it and sign-ins work again. Both directions ask for a confirmation.
Name and description
The name (3 to 50 characters) appears in the application switcher, the logs, the webhook messages and every other page. The description is for you only and never reaches your customers. Save is enabled once you change something, and Enter in either field saves. Renaming is instant and safe: the API key does not change and nothing has to be rebuilt.
Destructive actions (reset, delete, wipe files, remove resellers) are not here. They are in the actions menu on the Applications page, where they need an email confirmation.
Session timeout
A hard cap on how long one session may last: off, 15 minutes, 1, 4, 12 or 24 hours, 3 or 7 days. It is measured from when the session began, not from the last activity. When a session reaches it, Atlas ends it, the program's next heartbeat fails and the program closes, and the customer must sign in again. Use it against a login handed to friends who leave it running day and night.
Self-service resets
A customer can move a license or an account to a new PC without you. A reset clears the hardware and IP binding, ends the customer's live sessions and writes a row to Access rules, Recent resets. Each switch turns one way of resetting on, and all of them are off until you turn them on.
| Setting | What it does |
|---|---|
| Licenses, while signed in | The program resets the license it is signed in with. The old PC's session ends and the key binds to the next PC that signs in. |
| Accounts, while signed in | The same, for the account the program is signed in with. |
| Accounts, before sign-in | The customer types the username and gets an 8-digit code by email. Needs a verified email on the account. Licenses have no reset before sign-in. |
| Resets per 30 days | How many self-service resets one license or account may use in a rolling 30 days, 0 to 5. 0 turns self-service reset off for the whole application. |
| Quarantine for the released PC | The PC that was released cannot bind the key again for this many hours, 0 to 72. 0 lets it straight back in. |
| Alert rule resets per 30 days | How many resets one alert rule may make for the same license or account in 30 days, 0 to 10. 0 stops alert resets. A refused one is logged with the reason ALERT_CAP. |
| Lock after resets | When a license or account reaches this many self-service resets in 90 days, 2 to 10, the reset that reaches it still works. The next one is refused until you unlock the subject in Access rules. |
| Account deletion grace period | How long an account deleted from the SDK waits before it is removed, 0 to 30 days. 0 removes it at once. During the grace period the account's sessions end and signing in again keeps it. |
| Email on account deletion | Emails the customer when an account is deleted or scheduled for deletion. The email gives the date when there is a grace period. An account with no email cannot delete itself. |
A customer can reset once every 24 hours. Resets you, staff, a reseller or an API token make are never limited, and do not count toward the allowance or the lock. Alert rule resets have their own cap, in the table above. The switches save as you change them; a number saves two seconds after your last click.