# Administration

Updated: 2026-11-06

For workspace admins (and project admins for their projects).

## The Administration page

Workspace admins reach every admin page through one sidebar entry, **Administration**. It opens a page with:

- **Find setting:** type a word to find an admin page, a settings tab or a card on it (*mail server*, *Jira*, *time tracking* …) and jump there.
- **Needs attention** (a yellow strip, only when there is something): terms or DPA not accepted, invitations that expire within 3 days, failed webhook deliveries in the last 7 days, the last backup failed. Each item links to its page. The red number on the sidebar entry counts them.
- Four groups, one row per page with what it holds right now:
  - **People & Permissions:** Users (*8 active · 1 invitation*), Permissions, Connected Apps (*6 agents*)
  - **Projects & Structure:** Project Groups, Tags
  - **Integrations & Import:** GitHub, Webhooks, Jira Import, Confluence Import (*Connected* or *Not connected*)
  - **Workspace:** Settings (*AI on*), Plan & Billing (the plan), Backup & Restore (the last backup)

Every admin page keeps its own address; its breadcrumb starts with *Administration /*. Members and customers don't see the entry.

## Users

*Administration › Users* lists the people of the workspace and the open invitations. Deactivate users who leave; inactive users can be **deleted** for good (their issues and comments stay, shown as "Deleted user …"). Tab *Projects* on a user sets memberships.

### Accounts that belong to the person

An account can be in several workspaces. Here you manage the person's **membership**: role, active or inactive, projects, internal note.

- **Name, email, password and two-factor reset** can only be changed for your own account, and for an account created in your workspace that is in no other workspace. Otherwise IT4S tells you that the person changes it under *My Profile*.
- **Internal note and last sign-in** belong to your workspace. Another workspace of the same person sees neither, and you can edit the note for anyone in your workspace.
- **Deactivating** ends their sessions in this workspace only.
- **Deleting** an account that is also elsewhere removes them from this workspace. The account stays, and their issues and comments here keep showing their name.

### Invite Users

**Invite Users** (top right) invites people by email:

- **Email Addresses:** one or many, separated by commas or new lines. People who are already in the workspace are skipped; IT4S tells you which. Someone a Jira import added as inactive can be invited, and that is how they join.
- **Workspace Role:** Admin, Member, Viewer or Customer, the same for everyone in this batch. Viewers are free and only read (see [Roles and customers](https://it4s.at/en/help/guide/roles-and-customers/)). Customers only see the projects you add them to.
- **Projects:** they join these projects when they accept: as members, or as viewers or customers if that is their role.
- **Personal Message:** up to 300 characters, shown in the invitation email.
- **Send Invitations:** each person gets an email with a link that works once, for 7 days. They join with a new account or the one they have (see [Getting started](https://it4s.at/en/help/guide/getting-started/)), or accept on `app.it4s.at`. Once they joined, they appear as active users.

**Users on your plan:** pending invitations count as users, or as view-only people for the role Viewer. The note under the list shows how many users you have (for example *Free plan: 2 of 3 users*); *Plan & Billing* shows both. When the invitations would go over the limit, the dialog says so and you cannot send them; invite fewer people or upgrade to Team.

### Invited people in the list

- Invited people appear as rows with the status **Invited** (who invited them and until when the link works) or **Invitation expired**. The *Status* filter shows Active and Invited by default; pick *Inactive* to see the others.
- **Resend Invitation** (the paper plane on the row) sends a new link, valid for 7 days again; the old link stops working. An expired invitation counts as a user again once you resend it.
- **Delete** on an invited row revokes the invitation: the link stops working and the seat is free.

### Join without an invitation

People of your company can join by themselves once you have proved that the domain is yours. Under *Settings › Sign-in & Security*, with Google sign-in on:

1. Enter the **Allowed Google Workspace Domain** and click **Save**.
2. Add the DNS record IT4S shows where your domain is managed: type TXT, name `_it4s-verify.<your domain>`, and the value shown.
3. Click **Verify**. A new record can take a while to appear; if IT4S does not find it yet, try again later.
4. Turn on **Join Without an Invitation** and click **Save**. The switch is off until the domain is verified.

Then:

- Anyone who signs in with a Google account of that domain joins as Member. Change their role under *Users* afterwards.
- It is off until you turn it on. `gmail.com` and `googlemail.com` are refused, because anyone can have such an account.
- When the plan's users are used up, nobody more joins this way; they are told to ask an admin.
- **Keep the DNS record.** IT4S checks it once a day. If it has been missing for 7 days, the domain is no longer verified, joining without an invitation turns off, and workspace admins get an email. People who already joined stay. A temporary DNS problem changes nothing.
- **Changing the domain** ends the proof and turns joining off; verify the new domain.
- **Limiting sign-in** to the domain needs no proof: the Allowed Google Workspace Domain alone only narrows who may sign in with Google.
- On a workspace's own address, Google sign-in goes through `app.it4s.at` and comes straight back, signed in.

## Projects

*Work › Projects*: *Add Project* (workspace admins): key (2–10 letters, prefixes issue keys, fixed once there are issues), name, lead. Project admins edit:

- **General:** avatar, name, lead, default estimate unit, **Default Documentation Visibility** (Internal or Public for new documentation pages; public pages are shown to the project's customers), Active, and **GitHub**: whether pull requests change the status, and to which status when a PR is opened, merged or closed without merge.
- **Description**, **Members** (user + role), **Documentation**, **Internal** (internal note).
- Projects you no longer need can be archived or deleted; see [Archive or delete a project](https://it4s.at/en/help/guide/archive-or-delete-a-project/).

**Inactive projects** are read-only and hidden from the pickers. Their issues, releases and documentation pages show a banner *Project … is inactive – read only*, with **Activate** for project admins, and their fields show the values read-only. *Add Issue*, *Add Release* or a new page for an inactive project explain that nothing can be created there.

## Tags and Permissions

- *Tags*: workspace-wide tags with colours. New tags (from the autocomplete or a Jira import) get a colour of their own; to recolour many at once, select their rows and use **Set Color…**.
- *Permissions*: what Customers and Members may do (see [Roles and customers](https://it4s.at/en/help/guide/roles-and-customers/)); *History* shows the last changes; *Reset to Defaults*. A legend above the matrix explains the cells, and the rows are grouped (Issues, Comments, Attachments, Time, Documentation, Project). A cell is a fixed value (✓ or – with a lock), a switch, or a value with › that opens the choice.

## Settings

| Tab | |
|---|---|
| General | **Workspace** (name, address, logo, language, time zone), time tracking (hours per day, days per week), **AI Agents**; *Attachments* (max size, allowed types) and **What's New** (who sees the notice after an update) are folded; click their title to open them |
| Notifications | which emails IT4S sends; mail server (SMTP) with *Send Test Email* |
| Sign-in & Security | Google sign-in and allowed domain, proof of the domain, **Join Without an Invitation** (see *Users*), two-factor required |
| AI | AI on/off, model, Anthropic API key, *Test Connection* (AI summaries run only after a successful test). A notice above the switch says what turning AI on does with your data; turning it on asks once more, and the audit log keeps who switched AI on or off and when. AI results are labelled *AI-generated* |
| Integrations | Jira, Confluence (*Test Connection*), **GitHub** webhook |
| Legal & Data | **Terms and Data Processing Agreement** (which versions the owner accepted, when and for which company), **Silvertip Support Access**, and last the **Danger Zone** with **Delete Workspace** |

**Public addresses only:** the mail server and the Jira and Confluence addresses must be reachable on the public internet, like webhooks. An address on a private network is refused, and *Send Test Email* or *Test Connection* says so.

Silvertip support only sees your workspace when you allow it; see [Silvertip support access](https://it4s.at/en/help/guide/support-access/).

### Workspace name, logo and address

*Settings › General › Workspace*:

- **Name:** shown in the sidebar and the workspace switcher.
- **Logo:** shown in the sidebar and the workspace switcher. It is not in emails or in backups.
- **Language:** the language of a new workspace's sample issues. Each person's own language is set under *My Profile*.
- **Time zone:** what counts as today, dates, worklogs, reports and limits follow it; see [Time zone of a workspace](https://it4s.at/en/help/guide/time-zone/).

**Change Address** moves the workspace to a new address:

1. Click **Change Address** and enter the new one. IT4S checks it while you type: 4–32 lower-case letters, digits or hyphens, not reserved, not protected, not taken.
2. Confirm. You move to the new address, still signed in.
3. **The old address redirects for 90 days** and nobody else can take it in that time. You can go back to it during those 90 days.

The workspace's admins get an email about the change. Other people sign in again on the new address. Connected apps on `mcp.it4s.at` keep working; **tools that use the old address directly need the new one**, because not every program follows a redirect when it sends data. After 90 days the old address stops working and is free again.

Three-character, reserved and protected addresses are given by Silvertip: contact support@it4s.at.

### Terms and data processing agreement

The owner accepts the IT4S terms and the data processing agreement (DPA) for the company when creating the workspace (see [Getting started](https://it4s.at/en/help/guide/getting-started/)). *Settings › Legal & Data › Terms and Data Processing Agreement* shows the accepted versions, when, by whom and for which company, with links to both texts.

When Silvertip publishes a new version, the **owner** sees a dialog the next time they open the workspace: enter the company, tick the box, *Accept*. Until then, everyone else sees a short note that the owner still has to accept. Nothing else stops.

### Delete a workspace

*Settings › Legal & Data › Danger Zone › Delete Workspace*. Download a backup first under *Backup & Restore*: afterwards you can't sign in to get one.

1. Click **Delete Workspace** and type the workspace's address. You can say why you are leaving; that is optional.
2. The workspace is **locked at once for everyone**: nobody can sign in, and connected apps and API tokens stop working. All admins get an email with the date.
3. **After 30 days it is removed for good**, with its projects, issues, files, members and backups.

**Changed your mind?** Contact support@it4s.at before that date. Silvertip support can restore it until then, and nothing is lost.

People keep their IT4S accounts and any other workspaces.

### Connect GitHub

1. *Settings › Integrations › GitHub* › **Generate Secret**; copy it (shown once). Changes from GitHub are recorded in your name, "via GitHub".
2. On GitHub: repository › Settings › Webhooks › *Add webhook*: the **Payload URL** shown in IT4S, content type `application/json`, the secret, events **Pull requests, Pushes, Check suites, Check runs, Statuses**.
3. Name issue keys in PR titles, branch names or commit messages (`Fix login (WEB-42)`). PRs, branches and commits then appear on the issue; a PR moves the issue to In Review, to Done when merged. The card shows the last delivery.

## Imports, webhooks, connected apps

- **Jira Import:** imports a Jira project with its issues, comments, worklogs and files; re-running updates instead of duplicating. Each run shows when its Jira data was taken ("Jira data from …"). **Import** uses that data only if it is less than an hour old; otherwise the button reads **Refresh from Jira and Import** and downloads the project again first, so work logged and changes made in Jira since the analysis are included. To bring IT4S up to date with Jira, open the last run of the project and click *Refresh from Jira and Import*. See also [Jira import: field history and links](https://it4s.at/en/help/guide/jira-import/).
  - **Into which project:** under the Jira project, *Import Into* picks **a new project** (key and name; by default the Jira ones) or **an existing project**. With another key, Jira's keys are replaced: Jira `WEB-12` becomes `HP-12`, also where titles, descriptions and comments mention it. Into an existing project the issues join its own; a number already used there gets the next free one. Importing the same Jira project again keeps the keys it got the first time. You can change the choice on an analyzed run until you import it again.
  - **People:** Jira accounts are matched with the people of your workspace by email. Anyone else with an address from Jira joins as an **inactive user**, and their Jira history stays under their name. Someone who has no IT4S account yet gets one you can activate under *Users*. Someone who already has an account elsewhere can't be activated by you: **invite them with *Invite Users***, so nobody joins without being asked. If Jira hides a person's address, map them by hand in the run, or their history goes to the admin running the import.
  - **Status Map:** before you import, the page lists every Jira status of the project with the IT4S status its issues will get. The Jira status is shown as a chip in the colour of its Jira category (To Do, In Progress, Done), followed by an arrow and an icon:
    - **Green check:** IT4S knows the name (such as *Backlog*, *In Review*, *Done*).
    - **Warning:** IT4S does not know the name, so the status only follows its Jira category, for example *Declined* (category Done) would become *Done*. Check these rows: pick *Won't Do* for Declined, or *Backlog* for a status that comes before To Do in your Jira workflow.
    - **Blue check:** you picked the status. It applies to every issue with that Jira status, for this run only.
    - A warning row you leave as it is imports the prefilled status. A new analysis shows the automatic mapping again; *Refresh from Jira and Import* keeps your choices for that run.
  - **Fix versions** become releases of the project; an issue with several fix versions gets the first one.
  - **Components** become components of the project, with a short code made from the name (*Driver App* → `DA`); a component that already exists with the same name is used. IT4S issues have one component: an issue with several Jira components gets the first one, and a comment on it names the others. The analysis lists the components and the issues with several.
  - **Project avatar:** an avatar uploaded for the project in Jira becomes the IT4S project avatar, but only while the IT4S project has none, so an avatar you set in IT4S is kept. Jira's built-in icons are not taken over.
- **Confluence Import:** imports a Confluence space or page tree into documentation pages. Imported pages are always internal; make the ones customers should read public afterwards.
- **Webhooks:** send issue, release and worklog events to other systems (signed, with a delivery log).
  - **Custom Header:** for receivers that expect a key, such as `Authorization: Bearer …` or `X-Api-Key`. The value is stored encrypted and never shown again (the field then reads *Saved*; leave it empty to keep it, or clear the name to remove the header). It does not appear in the delivery log. Headers IT4S sets itself (`Content-Type`, `Host`, `X-IT4S-…`) cannot be used.
  - **Use Own Secret:** when the receiver gives you its signing secret, enter it (at least 16 characters, no spaces) instead of rotating to a generated one.
  - **Filters:** *Issue Types* and *Tags* send only events about issues of those types, or with at least one of those tags (case does not matter). Empty means no filter. They look at the issue as it is after the change, so the change that adds a tag already counts. Release events are always sent.
  - **From Claude:** workspace admins can list, add, change, pause, test and delete webhooks with an app connection that has *Workspace Administration* ticked (`list_webhooks`, `create_webhook`, …). The signing secret appears once in the answer.
- **Connected Apps:** all Claude and app connections; revoke here (see [Working with AI agents and other apps](https://it4s.at/en/help/guide/claude-and-apps/)).

## Backup & Restore

*Administration › Backup & Restore*, per workspace.

**Create Backup** makes a zip of this workspace's data and files to download. It holds no passwords or two-factor secrets, but it does hold the workspace's data, so keep it safe.

### Automatic backups

IT4S makes a backup of each workspace every night, in the same format. The list shows date and time, size, number of issues and status. Each row has a **download** icon; **Restore…** is in its ⋯ menu. In the list of your own backups and restores, **Delete** is last in ⋯ and asks first.

- **How long they stay:** 7 days on Free and 30 days on Team; the line above the list says so. The newest good one always stays. You can't delete them yourself.
- **Before restore …** in the list is the snapshot IT4S takes before overwriting a workspace. It stays just as long.

### Restore as a new workspace

Any admin. Click **Restore…**, choose *As a new workspace* and enter a new address. This workspace stays as it is.

- The copy is called *&lt;name&gt; (copy)*, with the same plan and trial end. Rename it under *Settings › General*.
- It has the same members and roles, and you become its owner. Someone who has left this workspace since the backup is in the copy as a deactivated user.
- It counts as one of your workspaces: an account owns at most 3 Free ones.
- It starts without connected apps, API tokens and pending invitations. Enter the integration secrets, set up the webhooks and verify the Google domain there.
- When it is done, the page and an email link to it. If it fails, nothing is left and the address is free again.

### Overwrite this workspace

The workspace's owner only. Click **Restore…** and choose *Overwrite this workspace*, or **Choose Backup** to upload a zip made in this workspace. Then type the workspace's address.

- **A snapshot of the current data is stored first.** If that fails, nothing is changed. To undo the restore, restore the snapshot.
- While it runs, the workspace is read-only for everyone in it. This can take minutes for a large workspace. For a day afterwards, everyone sees which backup it came from.
- People stay signed in, and API tokens and app connections keep working. Enter the integration secrets again, and verify the Google domain again if you use it. Restored webhooks are inactive: rotate their secret, set any custom header again and activate them.
- People's accounts are not changed: names and passwords stay as they are. Someone who left the workspace since the backup comes back as a deactivated user, and you activate them under *Users*.

Both kinds run in the background, so you can leave the page. Admins get an email when it is done or failed, and the restore is in the audit log. There is no restore of single issues or projects; the trash covers that.