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). 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), 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.

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); 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

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.

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.

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). 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.
  • 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).

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 <name> (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.