Skip to content

Admin Center

The Admin Center is a section of the left-hand menu for the things an IT administrator knows and has to pass on: how the organization is run, which logins belong to which system, who to call when something breaks, what has to be renewed and when, and the company’s own facts. It is organization-scoped, like everything else in Sencai: it shows the data of the organization you currently have selected, and what you see depends on your role there.

Menu item What it’s for
Overview (/gravity/admin-center) A page of cards: a Needs attention list (handbook pages due for review, without an owner or that may contain a secret, passwords due for rotation, responsibilities nobody holds), upcoming reminders, approvals waiting, who to call, a shortcut to Handover, how complete the company details are, and links to related screens elsewhere. A card only appears if you may read what it summarizes.
Company (/gravity/admin-center/company) The organization’s own facts. See Company.
Handbook (/gravity/admin-center/handbook) Written procedures and runbooks for people. See Handbook.
Passwords (/gravity/admin-center/passwords) Logins, keys and codes, stored encrypted. See Passwords.
Contacts (/gravity/admin-center/contacts) Who to call, who is responsible for what, and a printable emergency sheet. See Contacts.
Reminders (/gravity/admin-center/reminders) Dated reminders, in the platform and optionally by e-mail. See Reminders.
Handover (/gravity/admin-center/handover) What to pass on when an administrator changes. See Handover.
People & Access Members, elevation requests and approvals, and approvals. Moved here, see Where things moved.
Directory & Identity Your synced directory and the identity monitoring screens. Moved here.
Incident Escalation Who gets woken up. Moved here.

Each item appears in the menu only for people who may read it.

The handbook is a set of pages written in Markdown - plain text with simple formatting - where you describe how things are done: the network overview, how to onboard and offboard an administrator, backup and restore steps, who to call.

  • Pages and sections. Give a page a title and an optional section name. Sections are only a way of grouping the list; they are not an access boundary, so don’t use a section to hide a page from anybody.
  • Templates. New from template starts a page from a ready-made outline: company facts, network overview, onboarding an administrator, offboarding checklist, backup and restore, and who to call.
  • Pin the pages people reach for most; pinned pages appear on the Overview.
  • Search looks in titles and page text of the current organization. It accepts short queries only (up to 100 characters and five words); a longer query is refused with an error, it is not silently shortened.
  • Linking. Write [[page:<id>]], [[password:<id>]] or [[contact:<id>]] to point at another handbook page, a password entry or a contact. The title is looked up when the page is shown, using the reader’s own permissions, so the same page can look different to different readers:
    • Someone who may not read that kind of item at all (for example a Viewer looking at a link to a password or a contact) sees Restricted item, not its name.
    • A password in the restricted tier that the reader may not see (a Member) shows as Missing item, with the hint “This item does not exist or is not available to you”. It looks exactly like a link to something that was deleted, so the page never reveals that the restricted entry exists. Admins and Owners see its title.
    • A link to a page, password or contact that really is gone shows Missing item for everyone who may read that kind of item.
  • Size. A page is limited to 256 KiB of text.

Owners, review dates and “Still accurate”

Section titled “Owners, review dates and “Still accurate””

A page can carry an owner, a review interval in days and a handover-critical flag. When the interval runs out the page shows up as due for review on the Overview and in the list filter. Click Still accurate to confirm the page without editing it; that restarts the interval and does not create a new version. In the editor, the owner can currently be set to yourself or to nobody.

  • Every save keeps a full snapshot. Open the history to compare versions and restore an earlier one; restoring saves it as a new version.
  • If two people edit the same page, the second save is refused with an edit conflict instead of silently overwriting. You are shown what changed and can overwrite, take the other version, or keep editing.
  • Delete moves a page to the trash. People who can edit pages can open the trash, restore a page, and see trashed pages; Delete permanently and history redaction need the manage permission (Admin and Owner).

When you save, Sencai looks for things that look like secrets: private-key blocks, cloud access keys, tokens, and lines of the form password: something. Titles, section names and change notes are checked too. A match never blocks the save, but the page is flagged and you are warned, because handbook pages and their history are readable by many people. Move the value to Passwords and refer to it with [[password:<id>]] - such a reference is only a pointer and is not itself treated as a secret, so the warning goes away once the value is out of the text. If a secret has already been saved, an Admin or Owner can redact old versions: the text of that version is replaced by a marker. The current version cannot be redacted; edit the secret out first, then redact the older versions. The check is a heuristic, so a short, free-form password may not be recognized.

The password store keeps the secrets your administrators need to share: logins, SSH keys, API tokens, Wi-Fi passwords, door codes, license keys, recovery codes and secure notes. Payment cards are not supported.

Each entry has details and, optionally, values.

  • Details - title, kind, section, URL (http or https only), username, a description, owner, review and rotation intervals - are ordinary organization data, readable by everyone who may see the list. The description is not encrypted; never put a secret in it.
  • Values - password, secret, private key, TOTP seed, PIN, recovery codes, secure note - live only in Sencai Vault. They are never shown in the list, never part of a page you load, and never sent back by any call except an explicit reveal. Each value is limited to 16 KiB and an entry to 64 KiB.
  • Versions. Setting a value again creates a new version. The versions tab lists when each was set, by whom, and which fields changed (never the values), and lets you reveal an older version.
  • Rotation. Set a rotation interval to see entries that are due for rotation on the Overview and in the list filter.

If the secret store cannot be reached when you create an entry, the entry is kept without a value and shows “No value stored” so you can retry.

To see or copy a value you use Show, Copy or, for a stored TOTP seed, Show code. A TOTP code is generated for you from the seed without revealing the seed itself; revealing the seed is a separate, stronger action and is labeled as such. A code is shown once per click, with a countdown; use New code for the next one. Each code you view is recorded like any other reveal.

  • A shown value hides again after 30 seconds, when you leave the tab or the page, and when you close the entry. After 30 seconds Sencai tries to clear a copied value from the clipboard. Browsers sometimes refuse while the tab is in the background; the clear is then retried as soon as you come back to the page, and the page tells you it is still waiting. If you copied something else in another application in the meantime, Sencai cannot tell and clears the clipboard anyway. Clipboard history tools may keep their own copy.
  • Every reveal is recorded. Before a value is returned, a row is written to a durable access history (who, which entry and field, which version, when, and the reason if you gave one), and an audit event is published. If either record cannot be written, the reveal is refused and you see an error rather than the value.
  • Limits. One person can reveal up to 60 values per hour. Revealing many different entries within a few minutes raises a security alert for the people who can edit passwords.
  • Who can read the history. The access history is visible to people who can read the audit log (Owner, Admin and Auditor), in the entry’s Access history tab.

If Sencai’s secret storage is temporarily unavailable, the list and details keep working, but revealing, copying and changing values is refused with an explanation.

When you create an entry you can tick Require two-factor authentication (TOTP) to reveal. It is off by default for ordinary entries.

  • For an entry with this option, showing, copying, generating a TOTP code, revealing the seed and deleting it permanently each need a current code from your authenticator app. After you enter one, it is remembered in the browser for about ten minutes and is not kept across a page reload.
  • An account without two-factor authentication cannot reveal such an entry. Turn it on in your profile (User profile, /gravity/userprofile) first. Recovery of a lost second factor is a manual process through support.
  • Turning the option on later needs only permission to edit the entry. Turning it off also needs a fresh code, and is recorded in the audit log as a high-risk change.
  • The code comes from the authenticator you set up for your own account. You cannot swap that authenticator for another one while two-factor authentication is on: disable it first (which asks for a current code), then set it up again. This keeps a stolen session from replacing your authenticator with its own and then passing the check.
  • Entries without the option can still only be revealed by people holding the reveal permission, and are logged and limited exactly the same way.

An entry can be placed in the restricted tier, meant for things like root accounts. It is owner-controlled:

Role What they get
Owner Sees, changes and reveals it. Every reveal needs a reason and a fresh two-factor code.
Admin Sees the entry’s name and details, but cannot reveal its value and cannot change it.
Member and below Do not see it at all: it is missing from lists and its address answers “not found”.

The two-factor option is always on for restricted entries and cannot be turned off. The exact keys behind this are listed under The Admin Center permissions.

Delete moves an entry to the trash; its values stay in Sencai Vault and you can restore it. Delete permanently works only from the trash and destroys the stored values first. Organizations that still have password entries (including trashed ones) cannot be merged into another organization.

It is not a login autofill tool or a replacement for secret delivery to your servers. To deliver a value to a host, use Secret Injections under Fleet. Password entries are never readable through API tokens or AI agents.

A reminder notifies people at a date and time you choose.

  1. Open Reminders and choose to add one.
  2. Enter a title, an optional note (plain text, up to 2,000 characters), and the date and time in your local time zone. The time zone is stored with the reminder.
  3. Choose how often it repeats: once, daily, weekly, monthly or yearly. Monthly reminders on the 31st fall on the last day of shorter months.
  4. Choose recipients - by default, you. Recipients must be accepted members of the organization who can read reminders; people with a pending invitation or who have left are skipped.
  5. Notify in platform is on by default and shows the reminder in the notification bell. Tick Also send by e-mail to send an e-mail as well; the e-mail links to the reminders page.

On the list you can mark a reminder Done (this ends a repeating series as well), Snooze it (which also reopens a finished one-time reminder to “remind me again”), edit it, or delete it. The Upcoming, Done and All tabs, and Only mine, filter the list. A reminder is visible to everyone in the organization who can read reminders. Editing or deleting one is for its creator or an Admin or Owner; marking it done or snoozing it is also open to a recipient.

When a reminder falls due, the notification in the bell takes you to that reminder: the page opens on the tab that holds it - a one-time reminder that has already fired is under Done, not Upcoming - and highlights it. If the reminder has been deleted, or belongs to another organization, the page says so.

A reminder can point at a handbook page, a password entry or a contact. A Remind me button on each handbook page, password entry and contact card (and Add a reminder on the Overview) opens the dialog with the link and a suggested title already filled in, for example “Rotate” on a password. A reader who can’t see the target sees only that they have no access.

To keep mail volume sane there are limits: up to 1,000 active reminders per organization, and e-mail reminders are capped at 200 recipient-slots per organization and 50 per creator, where each e-mail recipient of an active reminder counts as one. A reminder that would go over a limit is refused with an explanation.

Contacts is the organization’s address book of the people and companies that matter operationally: internal IT, management, your internet and hosting providers, hardware and software vendors, an MSP, accounting, legal, the landlord, security contacts.

  • A contact can be a person or a company and carries a category, role, responsibilities, up to five e-mail addresses and five phone numbers, a website, availability or support hours, your customer and contract references, and notes.
  • Contacts can be linked to a member of the organization or to a password entry, and can be marked as an emergency contact.
  • The page has three tabs: Contacts, Responsibilities and Emergency sheet. The Contacts tab can be filtered by category, emergency contacts only, and contacts that are due for a check.
  • Cards from members creates cards for all accepted members who don’t have one yet in a single step, copying their name, work e-mail and job title. It needs permission to create contacts and to read members. A pending invitation never gets a card, and running it twice creates nothing the second time; the result lists who was skipped and why.
  • The Responsibilities tab is a matrix of areas (“Firewall and VPN”, “Backups”) with a primary and backup contact and an escalation note.
  • The Emergency sheet is a printable page of the emergency contacts and the responsibilities matrix. It contains no notes and no secrets.
  • A Remind me button on each card sets a reminder such as “Check the contact details” (see Reminders).

Contacts are personal data about third parties. They are removed immediately when deleted (there is no trash and no revision history) and never copied into the audit log. If you can change contacts but not read them (for example a custom role with edit but not read, or a personal deny on reading), saving an existing contact and creating or saving a responsibility still work, but the answer withholds the card and returns only its ID with a “content withheld” marker. Creating a new contact is the exception: the answer echoes back what you entered, plus the defaults.

When a person’s account is erased (a deletion request under the GDPR), every contact card linked to that person is anonymised: the name becomes “Former member” and the company, role, e-mail addresses, phone numbers, website, availability, notes and responsibilities text are cleared, and the link is removed. What stays is your organization’s own bookkeeping: the category, emergency flag, your customer and contract references, the review data and the card’s place in the responsibilities matrix, so a handover still shows that the slot existed.

Unlike passwords, contacts and the handbook can be read, read-only, by AI agents and tools using your API tokens. A token reaches the handbook pages, the contacts, the responsibilities matrix and the emergency sheet of its own organization only. Passwords are never reachable this way. Handbook text is returned as the raw Markdown; whatever consumes it must not render embedded HTML.

What a token can read depends on how it was issued, and the handbook and the contacts are separate permissions:

  • A key with restricted permissions reads exactly what was ticked when it was created: handbook:read for the handbook, contacts:read for the contacts, the responsibilities matrix and the emergency sheet. This is the way to give an AI agent access to contacts, and it is checked on every call. See Letting an agent read your contacts.
  • A default read token (no restriction) is meant for looking things up and is capped at what a Viewer may do. A Viewer reads the handbook, but not contacts, which are personal data and start at Member. Do not rely on a default read token for contacts: where this limit applies, the contact routes answer 403 and the MCP tools report permission_denied.
  • A read/write token acts with up to an Admin’s permissions, so it can read contacts as well. It needs your organization’s AI-agent write access switched on, and gives an agent more power than one that only reads should have.

In every case the token only reads what the person who issued it may still read: if that person is denied reading contacts, is demoted or leaves, the token stops reading them. Please account for this in your own records of processing: personal data in your contacts may be read by AI agents that you authorize.

In an MCP client (see AI agents (MCP)) these reads are the tools handbook_search, handbook_get_page, contacts_list, contacts_get and responsibilities_list. They return the handbook Markdown raw, mark it as untrusted data, and never take an organization ID. There is no tool for passwords at all.

Company (/gravity/admin-center/company) holds the organization’s own facts: a description, company ID, street and number, city, postal code, state or region, billing country (a two-letter code such as CZ), whether you are a business customer, phone, website, a contact e-mail, the workspace domain, and the VAT ID (checked against the EU VIES register). A blank field clears the stored value. The postal code is stored as a number, so leading zeros are not kept. The Overview shows how complete the details are and which are missing. Editing needs permission to update the organization (Owner and Admin); everybody else sees the page read-only, and a save attempted anyway (for example through the API) is refused with a permission error rather than applied. The same details are on the organization’s profile.

When an administrator leaves or changes role, Handover (/gravity/admin-center/handover) is where you prepare it for one person. Pick a member from the list and the page reports:

  • the handbook pages and password entries that person owns (titles and state only, never a value),
  • their contact card and the responsibilities where they are the primary or backup contact,
  • every handover-critical handbook page of the organization, with who owns it - the ones nobody owns are the gap a successor falls into, and
  • the passwords they revealed in the last 90 days, so you know which credentials to rotate.

Only someone who has accepted their membership can be reported on, so run it before the person is removed. A pending invitation or a person from another organization is “not found”.

What you see depends on your own permissions, and a part you may not read is left out and listed under Not shown to you instead of appearing empty. The password lists need permission to read passwords. The “revealed in the last 90 days” part needs that and permission to read the audit log, so in practice Owners and Admins; an Auditor sees who revealed what in the audit log but gets no password titles here. Entries in the restricted tier are listed only for people who may see that tier.

Handover only lists. It does not move or change anything, so after you review it, assign new owners to the pages and entries and update the responsibilities matrix; each row links to where that is done.

The Admin Center uses its own permissions, described on Permissions in depth. In short:

Area View Create and edit Delete Reveal passwords
Handbook everyone, including Viewer and Auditor Member and above Admin and above n/a
Passwords Member and above (details only) Admin and above Admin and above Admin and above
Restricted passwords Admin and above (details only) Owner Owner Owner
Contacts Member and above Member and above Admin and above n/a
Reminders everyone Member and above Member and above n/a

These are the standing roles’ defaults, and they are what is enforced for these five areas. Per-member denies and, as they become available, custom roles (see Roles & permissions) can take away or grant individual keys, for example a denial of password reveal for one Admin, or a helpdesk role that may reveal passwords. Sencai’s own platform administrators have no shortcut into any of these areas: they can only act in your organization through a membership you have granted.

Opening the Admin Center moved several existing screens. Only the menu entries moved; every address (URL), bookmark and link still works.

Screen Was under Now under
Directory, Org Units, Workspace Licences, Cloud Identity Settings Admin Center → Directory & Identity
Identity Watchdog (formerly “Watchdog”), Identity Security Posture Settings Admin Center → Directory & Identity
Escalation Settings Admin Center → Incident Escalation
Approvals Compliance & Audit Admin Center → People & Access
Elevation (requests and approvals) the command palette only Admin Center → People & Access
Members & Roles the organization’s Members tab only Admin Center → People & Access (opens that tab)

Secret Injections (Fleet), Cloud Credentials and Rotation Policies (Settings), the Knowledge Base (Support, which holds Sencai’s own help articles, not your handbook), Runbooks and Change Requests stay where they were; the Overview links to them under related screens.