Skip to content

Owner and admin guide

This page is for the people who run zGentic for their own organisation: the owner and the administrators. Everything described here lives under the Admin tab, which nobody else sees.

You do not need a technical background to do any of it. Where a setting has a technical name, the plain meaning is given first.

People and what they may do

Admin, then Users, lists everyone in your organisation. From there you can invite somebody, change their role, deactivate them, send them a password reset, or remove them.

Role What it allows
Owner Everything an admin can do, plus billing and the Debug tab.
Admin Manage people, models, connectors, branding and spending limits.
Member Use chat, projects and agents. No settings.
Viewer Read what has been shared, without changing anything.
Reviewer Everything a member can do, and may also decide on work that needs approval.

Removing someone deletes their private chats and their personal memories, and releases their files. Nothing of theirs is left stranded. What they contributed to a shared project stays with the project.

Business units

Admin, then Subtenants, lets you model business units inside your organisation — a department, a country, a subsidiary. A connector, an agent or a model setting can be limited to one business unit, and something shared can be shared with a single unit instead of the whole organisation.

If your organisation does not need that separation, you can ignore this section entirely.

Billing & usage

Admin, then Billing & usage, is where the money is.

  • Available balance — what you were granted plus anything you have bought. Top up starts a payment.
  • Daily spend — a bar per day, split by model, including the cost of any code the assistant ran for someone. Show 7, 30 or 90 days. Export CSV gives you the full detail per day, person and model, for your own spreadsheet.
  • Usage and limits per person — what each person has spent, and a monthly limit you can set for them individually. When someone reaches their limit they are told so plainly, and their work stops until the next month or until you raise the limit. Their colleagues are not affected.
  • Model pricing — what each model costs your organisation, quoted per million tokens, listed separately for text going in and text coming out.

Two things worth knowing about how this is enforced:

Spending stops, it does not accumulate. When the organisation's balance runs out, work is refused with a clear message. There is no invoice arriving later for usage you did not know about.

Warnings come before the wall. People are warned as they approach their own monthly limit, and owners are alerted when the organisation's balance is getting low. New organisations start with a small trial balance.

Understanding what you are paying for

Models are billed by the amount of text they handle, measured in tokens — a token is a chunk of text a little shorter than an average word. Prices are quoted per million of them. Text you send counts, and so does the text the model writes back, usually at a higher rate.

This means a long conversation costs more than a short one, because the earlier messages are sent again each time so the model knows the context. Switching Thinking on also costs more, because the model writes out its reasoning before it answers.

You will also see a small amount of compute in the figures. That is the assistant running a short program it wrote itself — to turn a table into a spreadsheet, for instance — charged by the processing time it used. It is usually a rounding error next to the models.

Everything that reached the supplier is listed, including what did not finish. Each round records whether it succeeded, came back empty, failed, or was cancelled — because someone pressed Stop, or because a piece of work hit its limit. Those rounds are charged: the text had already been sent and the supplier billed for it. Listing them rather than dropping them is deliberate, so the total you are charged and the total you can see always agree. Export CSV has an outcome column, which is the quickest way to tell a genuinely expensive day from one inflated by failures and retries.

The token figure shown on an individual answer in the chat is an indication for the person reading it. Your billing is calculated separately, from the counts your supplier reports, so the two can differ slightly — the daily-spend view and the CSV export are the authoritative record.

Models

Two settings control which models your organisation uses.

Admin, then Model backend, is where you choose whose models you use and enter the account details for it. This is the supplier relationship: one account, held once, for the organisation.

Model settings is where you decide which of that supplier's models your people may pick, which one is used when they do not pick, and the order to fall back through if a model is temporarily out of service.

  • Sync asks the supplier for its current list of models and their prices. Run it once after you set the supplier up, and again whenever you add a model. If you skip it, the pricing table stays empty and nobody can see what anything costs.
  • Nominate a model that can look at pictures. Your people then never have to think about it: when somebody attaches a photo, that model is used for the picture.
  • Provider caching lets your supplier hold on to a long, unchanging part of a conversation between calls, so it is not paid for again every time. Which options exist depends on the supplier, and each one explains what it does. Web search, opening a web page and knowing today's date are built into zGentic itself, so they are not listed here.

Connectors

Admin, then Connector marketplace, lists the connectors you can install, grouped by what they are for — utilities, web, productivity, developer tools, data, cloud, monitoring, and connectors that run on your own network. Each is marked free or sign-in required, and verified when the people who run the platform have checked it.

  • Install adds the connector to your organisation. You can restrict it to one business unit.
  • Installing never stores anybody's password or account access. Connectors that need an account are authorised by each person individually, so what comes back always respects that person's own permissions.
  • You can add a custom connector by its address, for a system of your own.
  • Your people then switch connectors on for a chat, a project or an agent — see Connectors.

Admin, then Egress, controls which outside addresses zGentic is allowed to reach at all. It applies to connectors and to opening web pages. Use it if your security policy requires a fixed list of permitted destinations; the default is workable without it.

Web search is part of zGentic and is powered by Perplexity. Until an account for it is configured, your people see Unavailable on the web search control and cannot switch it on.

To turn it on, either add your organisation's own Perplexity key under Admin, then Web search, or ask the people who run the platform for you to configure a shared one. From then on every member can switch web search on for individual chats; the choice stays theirs, per chat.

Branding

Admin, then Branding, accepts a theme package: a theme.zip file containing your colours, your logo and a welcome message. Once uploaded it is applied throughout the web application for your organisation, including the sign-in page.

Notifications and product-update email

Each person chooses how they want to be notified — in the application, by email, or by push message on their phone — in their own profile settings.

Emails about what is new in the product are switched on for everybody by default, and anyone can unsubscribe in their notification settings.

The diagnosis view

Owners have a Debug tab in the lower-right corner. It shows the technical detail behind your own recent activity: which model was called, which documents were searched, which code was run.

It is there to help you work out why something behaved the way it did. It never shows anybody else's activity.

Work that needs approval

If your organisation uses approval steps, work that needs a human decision waits and creates a review task for the people assigned to it. They approve it, reject it, or ask for changes. The work then carries on by itself. Reviewers are notified through whichever channels they chose.