# Administration (/docs/administration) Administration is where you manage your **workspace**: who is in it, a record of what happened, and how much of your plan you are using. Most of it is the job of an **admin**; everyone in the workspace can work on the apps. ## Your workspace [#your-workspace] A **workspace** is the shared home for everything your team does in Ovidens: its apps, data, and members. Anyone you invite can see and work on the same apps, so a workspace usually maps to a team or a company. The first time you sign in you set your workspace up: Ovidens greets you with "Name your workspace to finish setup and open it.", asks for an **Organization name** (the name everyone in your organization will see), and optionally lets you **Add billing details** - a postal address for your invoices, which you can skip and add later. **Create workspace** finishes setup and takes you straight in. If you belong to more than one workspace, switch between them from the workspace switcher at the top of the left navigation; each keeps its apps, data, and members completely separate. When you return to [app.ovidens.com](https://app.ovidens.com) while signed in, Ovidens opens your apps automatically. If you belong to several workspaces, it reopens your remembered workspace when you still belong to it; otherwise it asks you to choose one. If your session has ended, sign in again to continue. Any unfinished workspace setup comes first. The workspace name is not permanent. An admin can change it, and pick the icon and colour shown next to it in the sidebar, on the **General** tab of the **System** page under **Identity**. ## Members and roles [#members-and-roles] The **Access** page lists everyone in the workspace on its **Members** tab. Each member has a **role**: * A **Member** can work with the apps their roles open (see **Access** and **Default access for new members** below). * An **Admin** can do everything a member can, plus manage who is in the workspace. Everyone sees the member list. **Invite user**, the **Pending invitations** list and **Remove** are for whoever may manage members: an admin, or a member who has been given **member management**. Deciding what someone may do - the **Workspace role** column, **Manage access**, and inviting someone as an admin - stays with admins. A member without either sees the list and nothing else. The list is one table you can search by name or email and filter by workspace role. Beside each person it shows their **Workspace role** and, for admins, the roles they hold **On spaces**. For an admin, the person's name and the gear on their row (**Manage access**) open a dialog with their **Access** and **What they can do**. The row's menu offers **AI permissions**, **Activity log** and **Remove from workspace**, each only to whoever may use it; when you may use only one of them, it is a button on the row instead. Copy an email with the copy button beside it. To invite a teammate, open **Access**, select **Invite user**, enter their email, pick their role, and send the invitation. If you manage members without being an admin, the dialog has no role choice: everyone you invite joins as a member. They appear under **Pending invitations** until they accept, then move into **Members**. From that list you can **Copy invite link** to send the invitation yourself, or **Cancel invitation** for one that has not been accepted. A new member starts with no access: they have their own personal space and nothing else until somebody gives them a role, unless your workspace sets **Default access for new members** (below). The invite form says so as well. Someone invited as an admin is an admin from the start. An admin changes someone's **Workspace role** in their row: the change saves at once, with **Undo** in the message that confirms it. Making someone an admin, or taking an admin's rights away, asks you to confirm first. Someone whose admin rights are taken away stays in the workspace as a member and keeps their own work. Any invitation they sent to join as an admin that nobody has accepted yet is cancelled with it, and an admin invitation can only be accepted while the person who sent it is still an admin. An admin cannot be removed from the workspace until their admin rights have been taken away. **Remove from workspace** always asks you to confirm. ### Removing a member who has their own apps [#removing-a-member-who-has-their-own-apps] Every member has a personal space that only they can see. In it they build, publish, run and archive their own apps, write and run their own SQL queries against them, protect and delete their runs, and delete trashed knowledge-base pages for good. A query there reads only the app it is run in, never another app. Nobody else can open a personal space, an admin included. When you remove someone whose personal space holds apps, the confirmation tells you **how many** there are - never which ones, since nobody but their owner sees them - and asks what should happen to them before **Remove** is available: * **Move to** a team space moves every one of their apps there, where the people with access to that space can work with them. Only the team spaces you can create apps in are offered. * **Archive them** archives every app where it is. Nobody sees them, they stop counting against your app limit, and they are deleted for good once the archive retention period has passed. If the person rejoins before then, they find the apps in their own archive and can restore them. If their personal space is empty, the confirmation asks nothing more. Removing a member also disconnects every AI tool they had connected to this workspace; if they rejoin, they connect it again. ### Access: a role on the whole workspace, one space or one app [#access-a-role-on-the-whole-workspace-one-space-or-one-app] **Manage access** on a member's row (admins only) opens their **Access**: every role that person holds and where it applies - the whole workspace, a space, or a single app - one row each, with the role changeable in place. It is where you give somebody a narrower role than admin, or a role on less than the whole workspace: for example **App builder** on one team's space so they can configure and publish that team's apps and no others, or **App builder** on a single app so they can change that one app. To give a role, pick the space or app (or the workspace) under **Add access**, then the role. The choices offered are only the ones you are allowed to give there: personal spaces and the Audit Analytics app are never offered, and neither are archived apps. A role that would add nothing - because the person already holds as much there through another role - is not offered, and a row another role already covers is dimmed and says which one. The roles are: * **Admin** - everything, including deciding what everyone else may do. * **App builder** - create, configure, publish and archive apps (with Vera too), and work with their data. * **Analyst** - read an app's configuration and data, run it, and download its data. * **Contributor** - read an app's configuration and data, enter data (by hand or by importing a file), and download it. What a new member holds when they join is the workspace's default access for new members (below). * **Viewer** - read an analytic app's published dashboard, its knowledge base and its data, without its configuration, drafts or history, and without downloading the data or running AI on it. * **Member manager** - invite and remove members (on the whole workspace only). * **Reporting manager** - run an indicator app's collection: its reporting timeline, collection rounds and the people asked, the review of answers, and submitting, approving and reopening reporting periods (with Vera too). It reads the apps it covers and their configuration and data, and changes neither. Give it on one space or one app, for example to a sustainability lead who runs the reporting there and has no other administration. It does not enter figures on its own: somebody who also enters figures holds **Contributor** beside it. An **App builder** does not run collection, so the person who designs an app is not the one who approves what was collected in it, unless they are given this role too. To take a role away, select **Remove** beside it. Every change saves at once, with **Undo** in the message that confirms it. If a change is refused - for example because it would remove the last admin - the message says why and nothing changes. Your own access is shown but cannot be changed here. **What they can do**, the dialog's second view, shows what the person may actually do and why: for the whole workspace, for each space and each app they hold a role on, and for their own personal space, every permission they have there, each with the role that gives it ("App builder on Finance"). A space or an app lists what their roles on the whole workspace allow as well, so each place reads complete on its own. Their personal space shows only that they can always work in it - never what is in it. ### My access [#my-access] Every member can see what they themselves may do on the **Access** page's **My access** tab. It is the same view as **What they can do** in an admin's dialog, about you: for the whole workspace, for each space and app you hold a role on, and for your own personal space, every permission you have there and the role that gives it. Your personal space is listed as yours. To be given more, ask an admin: they give roles through **Manage access** on your row. A role on a space or an app decides what the person may DO there: configure, publish, enter data, download, and what Vera and connected AI may do on their behalf are decided app by app. It also decides which apps the person can see at all. In every app list and in search, each person finds only the apps a role of theirs covers - a role on the whole workspace covers every app, a role on a space covers the apps in it - and an app no role of theirs covers behaves for them as if it did not exist, for Vera and connected AI acting on their behalf too. A **Member manager** role on its own opens no app. What a person may read of an analytic app they can open depends on their role. A role that reads the app's configuration - **Contributor**, **Analyst**, **App builder** and **Admin** - opens the editor (read-only where they may not configure) and reads the draft, every node's configuration and SQL, the version history and the skills. A **Viewer** reads the app as it was last **published**: its dashboard pages, with each SQL widget showing its rows but never the query behind it, its knowledge base and the data behind them. A Viewer does not see that a draft is being worked on, is offered no **Open editor**, and opening the editor's link takes them to the dashboard instead. An app that has never been published shows a Viewer its empty state. An **indicator app** is read the same way. A Viewer reads its indicators, groups, dimensions and checks as they were last **published** - each indicator in full, with its guidance, unit, framework mapping and rules, and a calculated indicator with its calculation - and its collected figures exactly as everyone else does, together with its reporting periods and the collection rounds they are asked in. The reporting units in those rounds, in their own tasks and in the app's **Round progress** table and its companion tables carry the names that were last published, and a unit added only in the draft does not appear to them at all. A Viewer does not see the draft being worked on, the version history, Vera's work or the editor's checking tools, is offered no **Open editor**, and opening the editor's link takes them to the app instead. An indicator app that has never been published tells a Viewer that it has not been published yet. A **survey app** is read the same way. A Viewer reads the form as it was last **published** - every question exactly as respondents were asked it - and every response that has come in, together with the files people attached. The survey's **Information** page, its counts and its collection rules read the same for everyone. A Viewer does not see questions being drafted for the next round, the version history, the share link or the form editor's checking tools, is offered no **Open editor**, and opening the editor's link takes them to the survey instead. Downloading the responses as CSV is not part of the Viewer role. A survey that has never been published tells a Viewer that its responses appear once someone who manages the survey publishes it. If someone follows a link to an app they cannot open, they see **App not found** with the line "This app does not exist, or you do not have access to it." and the names of the admins who can give them access - up to three, then "and N more", or the person who shared the link when there is no other admin. The page never says which of the two it is, so it does not reveal whether the app exists. To let them in, give them a role on the app, on its space or on the whole workspace. The workspace always keeps at least one admin, so removing the last admin's rights is refused before anything changes: make someone else an admin first. Your own workspace role and **Remove from workspace** are not available on your own row - another admin changes your role. In a member's menu, **AI permissions** sets the most that person's AI may do in this workspace (see [MCP](../integrations/mcp.mdx)), and **Activity log** opens that member's history in the Audit Analytics app. ### Roles and spaces [#roles-and-spaces] **Roles**, on the **Access** page, is for everyone: it lists every privilege, grouped by area, with a column per role marking whether it allows it, and says under a privilege when it can be given only on the whole workspace or a space. Click role names in the header to compare those roles (**Add a role** brings back one you no longer see), and choose **Only differences** to see where they differ. Roles cannot be changed. A role given on a space or an app allows only what can apply there - **Admin** on a space, for example, does not let anybody manage members. **Spaces** is one table of the **Workspace** and each team space, with the default space first: who holds a role there, how many apps it holds and what they store. A role on the whole workspace applies in every team space too, so it is listed once, at the top, rather than under every space. Personal spaces are never listed, because only their owners can open them: the tab says only how many members have one and how many apps are filed in them. The tab also shows how much storage the workspace uses against its limit, and what each shared space's apps store. Personal spaces count against the same limit, so the tab says what members' personal spaces store together - never what one person's space stores, and only once at least three colleagues' personal spaces hold data; until then that figure is counted with the files that belong to no app. What belongs to no app (audit originals, attachments and other workspace files) is shown as its own figure. The figures per space are measured once a day, and the tab says on which day. It also shows how many shared spaces the workspace has against its limit, for example "3 of 10 team spaces in use". Admins manage the shared spaces here. Selecting a team space opens **Space settings** - the same space settings as on the **Apps** page - with its **Access** and, on **Details**, its name, its icon and **Delete**: * **New space** creates one. Give it a name of up to 80 characters that no other shared space already has (capital letters do not count as a difference). When the workspace has reached its limit the button is unavailable and says why; the Ovidens team can raise the limit. The default space counts towards it; personal spaces never do. * Changing the **name** on **Details** renames a space, the default space's included. Roles given on the space and the apps in it are not affected. * **Delete**, on **Details**, removes a shared space after you confirm, but only an empty one: if it still holds apps (archived ones included), roles given on it or defaults for new members, the delete is refused with how many of each are left. Move its apps to another space with **Move to another space** on the **Apps** page, where you see who gains and loses access before anything moves, and remove its roles and defaults here on the **Access** page first. The default space cannot be deleted. Every one of these changes is recorded in the activity log. A member who manages members without being an admin sees the **Spaces** tab too, listing the shared spaces they can open - but not who holds which role in them, which stays with admins. Anyone else sees **Members**, **My access** and **Roles**, and following a link to **Spaces** tells them that only someone who manages members or decides what they may do can see it. ### API credentials [#api-credentials] A connected system - a nightly import, a script, a scheduler - signs in with an **API credential** rather than a person's account. Credentials are on the **Access** page beside the members, on the **API credentials** tab, which only admins see. Everything about a credential happens there: creating one and copying its secret (shown once), seeing what it may do, rotating its secret, changing its access and revoking it. The tab is one table - each credential's name, key, access options, when it was last used and when it expires or must next be attested - and the gear on a row opens its details. The **Access** tab of a credential's details lists every permission its access options give it and which option gives each one, the same way a member's does. A credential holds no role, so it works in every shared space and every app in one, including apps created later, and never in anyone's personal space. See [Connected systems](./connected-systems.mdx) for the walkthrough. ### Default access for new members [#default-access-for-new-members] Everyone who joins the workspace from now on - by accepting an invitation with an account they already have, by signing up through an invitation, or by being added by the Ovidens team - receives the roles listed under **Default access for new members** at the bottom of the **Access** page's **Members** tab, plus their own personal space. Someone invited as an admin is an admin as well; any other invitation gives nothing beyond the defaults. Admins see this section and change it there; nobody else sees it. Every workspace starts with no default access: a new member holds no role until somebody gives them one, and until then works only in their own personal space. Members who had already joined keep every role they hold. A sentence above the list says what new members get. To add a default, select **Add default** at the right of the heading, pick the workspace, a space or an app in the dialog (you can search them), then the role, and select **Add default**: it is added with **Undo** in the message that confirms it. For example, **Viewer** on a team's space lets every newcomer read that team's dashboards and nothing else. Only roles you are allowed to give are offered, a role already set there is not offered again, and **Admin** and **Member manager** on the whole workspace are never offered: a default can never make somebody an admin or let them manage members. A workspace can have up to 20 defaults. To stop giving one, select **Remove** beside it; that also offers **Undo**. If a change is refused, the message says why and nothing changes. Changing the defaults never changes the roles of anyone who has already joined - to change those, use **Manage access** on their row. The defaults are read when a person joins, not when they were invited, so an invitation that is still open gives the defaults as they stand when it is accepted. A member whose roles open no app yet - for example in a workspace with no default access - sees "No apps are shared with you yet" on the apps page, with the names of the admins they can ask for access, instead of an empty workspace. If their list of apps could not be loaded, the page says so and offers **Try again**. If you would rather be shown than told, the Access page can walk you through its Members tab: [take the tour of the Access page](https://app.ovidens.com/access?tour=users). A tour only points things out; it never changes anything. ## Activity log [#activity-log] Your workspace records who changed what and when, automatically, on every change: apps created, data edited, pipelines run, teammates invited. Admins read that record in the **Audit Analytics** app, and reach it from anywhere in the product through the **View audits** button. The [Audits](../administration/audit-trail.mdx) page is the full walkthrough. Which AI model powers Vera is a per-workspace choice a workspace admin makes on the **General** tab of the **System** page - see [Choosing the workspace AI model](../infrastructure/ai-transparency.mdx#choosing-the-workspace-ai-model). ## The System page [#usage] The **System** page has these tabs. API credentials are not among them: they are on the **Access** page's **API credentials** tab (see [API credentials](#api-credentials)). * **Usage** names your workspace's compute tier and instance, which is what chiefly drives the readings below it, and shows the workspace-wide caps against a live current value: apps, users, audit log entries, stored data, monthly compute credits, monthly AI credits and team spaces. Below that, a chart of usage over time you can switch between **AI credits**, **Compute credits** and **Storage**, by hour, day, week or month. Admins - whoever may read the workspace's activity records - also see **Data downloads** at the foot of the tab: what members of this workspace downloaded - who, from which app and node, whether it was the current data, a version or a run, how many rows and how much - with the 30-day totals above it. A download that was narrower than its node is marked **filtered** or with the number of columns taken, so a small file is never mistaken for the whole dataset having left. A download from an app you cannot open - one in a colleague's personal space - is neither listed nor counted in the totals. Records are kept for 90 days; the files themselves are removed much sooner. It is the same question the [Credentials](../integrations/api/credentials.mdx) page answers for an automated system, asked about people. * **Limits** shows the fixed caps that apply per app, per version and per Visualisation - how many nodes, knowledge-base items, widgets, indicators, dimensions or skills each may hold - together with how much run data is retained per app and how long an archived app is kept before it is purged. * **General** holds your workspace **Identity** (name, icon, and colour) and its **AI configuration** (the model that powers Vera). An admin edits both and saves them together with one **Save**; everyone else, including a member who manages members, sees them read-only. [Take the tour of the System page](https://app.ovidens.com/system?tour=system) to be shown each tab on the page itself. ### When you reach a limit [#when-you-reach-a-limit] Two of the meters can stop work, and both say so plainly rather than failing silently: * **AI credits** reset monthly. At the monthly limit, AI features stop with a message naming the workspace's limit and pointing you at support; the rest of the workspace keeps working as normal. * **Compute credits** also reset monthly, and pay for running pipelines and reading data. At the limit you get "Monthly compute-credit limit reached for this workspace." until the next month begins, or until an admin arranges a higher budget. This stops reading as well as writing: dashboards, Visualisation pages, data previews and exports all report the limit rather than loading, because reading data costs compute in the same way running a pipeline does. Raising the budget takes effect immediately - the next page load works, with nothing to restart and no waiting period. Other limits, such as the number of apps, members or shared spaces, simply refuse the action that would exceed them and tell you which limit you hit.