Skip to content

Usage terms

The usage terms are a block of Markdown a site shows on its login page (Settings > General > Usage Terms). By default they are informational: signing in counts as agreeing, and the text sits behind a collapsed Usage Terms link under the sign-in form. A site can instead require every person to explicitly tick I have read and agree to the usage terms before they are signed in, and can make everyone agree again whenever the wording changes.

How it behaves

Three settings on the General tab control it. All three live on the site record, so they apply to everyone who signs in to that site.

Setting siteConfig key Effect
Usage Terms (Markdown) usageTerms The wording. Blank hides the login-page link and switches enforcement off.
Require explicit agreement at sign-in usageTermsEnforced Off (default): signing in counts as agreeing. On: people who have not agreed to the current wording must tick the box before they get a session.
Terms effective date usageTermsDate The date the current wording applies from. Each agreement is recorded against the date in force at the time.

With enforcement off nothing changes at sign-in. The terms are shown behind the collapsed link only.

With enforcement on, sign-in runs in this order:

  1. The person enters their email and password as usual.
  2. The API checks the password without issuing a session.
  3. If this person has never agreed on this site, or the date they last agreed against is earlier than the current Terms effective date, the sign-in form is replaced by the terms: the full wording in a scrollable box, a tick box, and Agree and continue. The button stays disabled until the box is ticked. Cancel returns to the sign-in form without agreeing.
  4. Agreeing records the agreement and sign-in carries on. If the site also requires two-factor authentication, that challenge comes next, after the terms.
  5. People who have already agreed to the current wording are not asked again; for them sign-in is unchanged.

The wording shown at step 3 is sent by the API at that moment, not read from the browser's cached copy of the site, so a freshly edited setting is what people agree to.

What is recorded

Each agreement is one row in the contactTermsAcceptance table (one per agreement, never updated), holding the contact, the site, when they agreed, from which IP address and browser, the Terms effective date in force at the time, and a SHA-256 hash plus a verbatim copy of the Markdown they were shown. The most recent row is "when this person last agreed"; the whole table is the audit trail of who agreed to which wording. Nothing is stored on the contact record itself (that table cannot take new columns).

How the effective date works

The date is the version of the terms. The gate compares the date on a person's latest agreement with the date now configured:

  • No agreement at all: asked (reason shown as Usage terms).
  • Latest agreement dated earlier than the current date, or made while no date was set: asked again (heading Our usage terms have changed, with the date they last agreed shown).
  • Latest agreement dated on or after the current date: not asked.

So changing the wording and moving the date forward is how you make everyone re-affirm. Changing the wording alone does not re-ask anyone; the date, not the text, drives it. Leaving the date blank asks only people who have never agreed on this site.

Why does it change unexpectedly

  • Everyone is being asked to agree again. An administrator moved the Terms effective date forward, or set one for the first time (an agreement made while no date was set counts as older than any date).
  • Someone is asked although they agreed last week. Their agreement was recorded against an earlier date than the one now set. Agreements are per site, so agreeing on one site does not carry to another.
  • Nobody is asked, even though enforcement is on. The Usage Terms text is blank. Enforcement needs wording to show, so blank text switches the gate off.
  • The terms step never appears for API integrations or single sign-on. Only the standard sign-in form (login/doLogin) runs the gate. Token exchanges on api/auth, Microsoft/Google sign-in, and refresh-token renewals do not, so people using those routes are never asked.
  • Someone was signed in before the date changed. The gate runs at sign-in only. An open session is not interrupted; that person is asked at their next sign-in.

What it is not

  • Not the login message (loginMessage): that is an always-visible notice above the sign-in form and is never agreed to. See site settings.
  • Not two-factor authentication: that proves identity; the terms step records consent. Both can be on at once; the terms come first. See two-factor authentication.
  • Not a document sign-off: deal sign-offs record agreement to a specific document by named people; this records agreement to the site's terms by everyone who signs in.