System settings

The system-wide defaults live at Administration → System settings in the admin user-menu dropdown. They cover how access defaults when permissions are not set, who may create an account, who must use two-factor sign-in, the per-file attachment size limit, the format of customer notification emails, how long sent-mail archives are kept, and reply signatures. The page is admin-only.

Permissions

Permissions model — Permissive or Restrictive. This controls how Tickiti behaves when a new queue is created:

1. Permissive (the default) — a newly created queue is automatically granted Contribute + Manage + Delete to every staff user. Good for small teams who treat all queues as open by default.
2. Restrictive — a newly created queue starts with no permissions; the admin has to grant access deliberately. Good for larger teams where queues correspond to separate functions.

Switching this setting only affects future queue creation; it does not retroactively change permissions on existing queues. See Queue permissions for the full per-queue picture.

Registration

These settings decide who can create an account on your site themselves, with Sign up on the login screen or Register on a customer ticket page. Accounts an admin creates in User admin are not affected.

1. Allow anyone to register — off by default. When on, anyone can create an account. When off, only addresses the eligibility service accepts can register; with no eligibility service set, self-registration is closed and the Sign up and Register links are not shown.
2. Allow registration with the system email domain — off by default. While it is off, addresses at the System email domain cannot register themselves, whatever the other settings say. Create staff accounts in User admin instead.
3. System email domain — your organisation’s own email domain, such as sole-provider.example. Addresses at that domain or any subdomain of it (uk.sole-provider.example) are staff addresses, and so are lookalike spellings of the domain — accented or full-width letters, similar-looking characters from other alphabets, other dash characters. Leave it empty to skip this check.
4. Eligibility service URL — the address of your own service that Tickiti asks whether an email address may register (see below). It must be an https:// address. Used only while Allow anyone to register is off. Leave it empty for none.
5. Eligibility service token — the bearer token Tickiti sends to the service. It is write-only: once saved it is never shown again, and the field reads Set - type a new one to replace it. Type a new token to replace it, or click Clear to remove it. The service is used only when both the URL and the token are set.

In every case, an address at the system email domain is refused unless Allow registration with the system email domain is on, and an address that already has an account is refused.

What a refused visitor sees. Every refusal shows the same message on the form: We couldn’t create an account with those details. If you already have an account, use Forgot password. It never says which check failed. An address that already has an account gets the same message, so the form cannot be used to find out which addresses are registered. No account is created and no email is sent.

The eligibility service

The eligibility service lets a system you already run — a CRM or customer database — decide who may register. For each registration that passes the checks above, Tickiti sends:

POST https://crm.example.com/api/registration/eligibility
Authorization: Bearer YOUR_TOKEN
Accept: application/json
Content-Type: application/json

{"email": "[email protected]"}

The address is sent trimmed and in lower case. To let it register, answer HTTP 200 with:

{"eligible": true}

Answer {"eligible": false} to refuse it. Anything else refuses the registration too: any other status code, a reply without "eligible": true (the JSON value true, not a string), a connection error, or no reply within 5 seconds.

Two-factor sign-in

Who must use two-factor sign-in — whether users have to add a code from an authenticator app to their sign-in (see Two-factor sign-in):

1. Off (the default) — nobody is made to use it. Staff can still turn it on for themselves from their profile.
2. Selected users — only users marked Must use two-factor in User admin.
3. All staff — every staff, admin and CRM user, plus anyone marked Must use two-factor.

A user who must use it and has not set it up is taken to the setup page the next time they open a page in Tickiti, and can use nothing else until it is done. While it is required, they cannot turn it off. Anyone who has set it up is asked for a code at every sign-in, whatever this setting. User admin shows which users have it set up, so you can check before choosing All staff.

Attachments

Max attachment size (MB) — the per-file size limit for inbound and outbound attachments. Default 50 MB. Files larger than this are rejected at the dropzone with an error; inbound attachments over the limit are skipped. The list of allowed and blocked file types is configured separately — see Attachment rules for that.

Email notifications

1. Notification mode — two options: Send responses in email includes the recent ticket replies in the notification email body, so the customer sees the conversation without leaving their inbox; Send notification email sends a short note with a link only, nudging the customer to read the conversation on the ticket page. Most teams use the latter; pick the former if your customer base struggles with the click-through.
2. Max responses in email — when Send responses in email is selected, this limits how many of the most recent responses are inlined. Default 2. Higher values make the email longer but less click-through to the ticket page; lower values keep emails concise but require the customer to read context on Tickiti.

Sent mail

Sent mail retention (days) — the housekeeping task deletes archived sent emails older than this. Default 90 days. Increase if you need a longer audit trail; decrease if storage is tight. See the Sent mail page (in the Mail menu) for the audit itself.

Signatures

1. Signature policy — None (no default signature), Anonymous (signed as the organisation) or Public (signed with the agent’s name). Choosing a policy fills in a starting default signature, which you can then edit.
2. Default signature — the text added to customer-visible replies. Placeholders are filled in when a reply is sent: {{user_name}} and {{user_first_name}} for the agent, {{public_contact_name}} and {{ticket_system_name}} from your branding.
3. Allow personal signatures — lets staff set their own signature in their profile, used in place of the default.

Agents can still change or drop the signature for any single reply — see Responding to tickets. Staff notes and tasks are never signed.

Saving

All the cards are committed together with the Save all button at the bottom right of the page. The save indicator next to the page title flips to Saving…, then Saved, so you have visual confirmation. Reload discards any unsaved edits and refetches from the server — useful if a colleague has been making concurrent changes.

Other admin pages

Other administrative areas have their own dedicated pages:

1. User admin — User management and per-queue permissions.
2. Queues — Queue configuration in the Workflow section of the Settings menu.
3. Mailboxes — Mailbox setup in the Mail menu.
4. Attachment rules — Attachment rules in the Mail menu.
5. Escalations — Escalations in the Workflow section.
6. Storage, Licence, API keys, Sent mail — each has its own page in Administration or Mail.

See also Satisfaction surveys and WhatsApp notifications.