Administration
Installation-wide settings: registration, AI agents, single sign-on, storage, search, integrations and the service's own pages.
Installation administrators see Admin in the user menu, under their name in the header. Administration holds everything that applies across projects. Wherever a setting depends on something managed on another page, such as a request form that uses custom fields, or a workflow that uses the statuses from Vocabularies, a link marked with a small arrow leads there.
This page covers the installation's own settings. The rest of the Administration section is on its own pages: Modules and features, where the modules and the features in each are switched on and off for the workspace, Managing projects, Vocabularies, fields and workflows, Imports, GitHub and GitLab, Export and import, the licence of a self-hosted installation and the plan of a hosted workspace.
Installation and registration
Set the organisation name, tagline and support contact shown on the home page, and the registration mode:
- Open: anyone may register.
- Invite only: accounts are created by invitation. Members invite people from Invitations in the user menu.
- SSO only: accounts are created only through single sign-on.
AI agents
Members can connect AI agents and scripts that work on tickets as them, through MCP and the REST API (see AI agents). The two are switched on separately under Modules and features, and both are off in a new workspace until you switch them on. Switching both off stops every agent and token in the workspace at once and stops anyone making a new one. Nothing is deleted, so switching one on brings them all back. An agent never has more than its member's permissions, and a deactivated member's agents stop with them.
Search
The search page under Administration shows whether the search engine (Typesense) is configured and reachable, each collection's documents against the rows it should hold (tickets, restricted comments, pages and activities), and when the index was last rebuilt. Rebuild index recreates the installation's index from the database in the background, with progress shown on the page: the tickets and their comments, and in the same run the knowledge base pages and the activities, which have collections of their own. The index holds derived data only, so it is never backed up: rebuild it after restoring a database or replacing the engine, or when the counts disagree. The page also lists what search covers: tickets, pages and activities come from the index, while projects, boards and customers are matched by key and name straight from the database and need no indexing. Below it, choose which content is indexed beyond keys, summaries, descriptions and labels: comments, work-log notes, attachment names and custom field text. Rebuild the index after changing these so existing tickets follow the new rule. See Searching for what people see.
Organisations and single sign-on
Organisations group people by company or department and list their email domains. An organisation is also a customer: the members section of its form gives people or groups a role on it, which applies to every project billed to that organisation (see Membership and roles), and whose CRM permissions apply to that company and its contacts alone. Who holds the CRM for every company is set under Administration, CRM access (see Who may see and change the CRM). A single sign-on connection attaches an OpenID Connect provider to an organisation; the form shows the redirect URI to register with the provider and a Test button checks the configuration. A connection can be enforced, so people from those domains must use it, and can create accounts on first login.
Connecting an account of your own cannot be tried in the public demo workspace, whose logins are everybody's: see In the demo.
Invoicing
The workspace's own details on invoices: the company name, address, phone and email printed at the top, the currency, a tax label and rate, and a footer for payment terms. See Invoice settings in the Time guide, and Customers and contracts for the customers, contracts and phases the invoices are made from.
Storage
Attachments live in an S3-compatible bucket you provide. Add a storage location with its endpoint, region, bucket and credentials, verify it, and mark one as the default. On a Docker installation the first location is created from the environment automatically.
On a hosted workspace a location marked provided is the service's own: your attachments live under a prefix of yours in storage the service runs, with the service's credentials. You can rename it, make another location the default, or archive it in favour of a bucket of your own; where it points and what it signs with are not yours to change, so the edit page shows only its name.
Connecting an account of your own cannot be tried in the public demo workspace, whose logins are everybody's: see In the demo.
Knowledge base
The knowledge base's workspace spaces are an installation administrator's to create, with New space on the Knowledge page; a project's space is made the first time somebody opens it, and follows the project's roles. Who reads and writes a workspace space, and whether customers and public forms see its published pages, is set in the space's own settings; see Space settings. A space can also be kept in step with a folder of a GitHub or GitLab repository; see Docs from Git.
Integrations
Connect GitHub or GitLab, so that commits, branches and pull requests link to tickets and pushes update the spaces read from Git. See GitHub and GitLab.
A workspace can receive mail as well as send it. The Email card under Administration shows whether mail is received, the address it arrives at, the last message received and what became of it, the messages held for review, and the recent messages in both directions.
Mail arrives through a provider. On the hosted service the workspace already has an address, shown on the page, and forwarding your own support address to it is enough; a self-hosted installation chooses a provider on the page (a message posted whole by its own mail server, an IMAP mailbox it reads every minute, or Postmark; the technical guide's Incoming email page sets each up), gives the address mail arrives at, enters the provider's credentials (a secret is never shown again once saved; leave the field blank to keep it, and a generated one is shown once) and switches Receive mail on. The largest message accepted can be set too; it is 25 MB when left blank. Nothing receives mail until the settings are switched on, and notifications carry no reply address before then.
What follows a plus sign in the address says what a message is for: a reply to a notification carries a reply address of its own, a helpdesk form can be given an inbound key so that mail to it raises a request, and a member can log mail on a contact. Every message is kept whole in the workspace's storage, and every outcome is recorded: a comment or request made, a message set aside as an automatic reply, a bounce or one of the workspace's own, one refused because the sender's domain says it did not send it (DMARC), one held because the provider called it spam or nobody answers at its address, one over the size limit, or one from a sender writing more than the hourly limit allows.
Held for review lists what was set aside. Accept runs a message through again, past the provider's verdicts, which is how a legitimate message that a check caught is let in; Dismiss marks it reviewed and leaves it. Check again reloads the page's figures, which is the quickest way to test the address: send a message to it and watch the last message received change.
Connecting an account of your own cannot be tried in the public demo workspace, whose logins are everybody's: see In the demo.
Calendars
Members can connect their own Google or Microsoft 365 calendar, so that meetings with contacts are logged on their timelines and scheduled calls and meetings reach the calendar (see Calendar). The Calendars card under Administration is where the provider is set up: for each one, the client id and client secret of an application registered with it, and whether members may connect. The page shows the redirect address to give the provider when registering; the technical guide's Calendars page goes through registering one with Google and with Microsoft.
On the hosted service both providers are there already and the page needs nothing; an application of your own, entered here, is used instead of the service's. A secret is stored encrypted and never shown again. Removing an application stops the calendars connected through it from being read until one is there again; what was logged stays.
iCloud needs no application: a member connects it with their Apple ID and an app-specific password they make at Apple. It is off in a new workspace, and switched on and off under Modules and features.
Each member connects and disconnects their own calendar on their account page. An administrator cannot read a member's calendar or connect one for them.
System dashboard
The System dashboard card opens Phoenix LiveDashboard for the running server: memory, CPU and disk, request and database query metrics, the processes and sockets of the node, and the log lines of a single request as it happens. It is for whoever looks after the installation and changes nothing about tickets or projects. Only administrators can open it. On a hosted installation it shows the whole service rather than one workspace, so it appears only for the administrators of the operator's own workspace; everyone else has no card and no page.
Installation check
The Installation check card checks the services the installation depends on and says, for each, what to change when it is not right: the database and whether every migration has run, Typesense, the attachment storage (an object written, read back and deleted, and whether a browser at the application's address may upload to it), the mail server, the public address people open the application at, and the licence. It changes nothing but the storage location's "verified" time. Like the System dashboard, it is there for the administrators of a self-hosted installation and, on a hosted service, of the operator's own workspace only. The same checks run from the command line; see Checking an installation.
Workspaces
On a hosted service, the administrators of the operator's own workspace have a Workspaces card. It lists every workspace on the service with its plan, where that stands (on trial, active, past due, suspended), the members it has now and the day its trial or its paid period runs to. Nobody else has the card or the page, and a self-hosted installation has neither.
One thing can be changed there: the last day of a workspace's trial. Setting it puts the workspace back on trial until the end of that day, up to about a year ahead, so it is not asked to pay and nothing is locked until then, whatever notices it showed before. A workspace that already pays through Stripe cannot be changed here, because Stripe states its trial; extend its trial there with a coupon. The operator's own workspace is never billed and a workspace that has been switched off is left alone.