Org Settings

What's on this screen

Org settings is where administrators manage settings that affect the whole Vibedata instance. Choose a panel in the left navigation; the panels available depend on your access and the deployment.

How to open Org Settings

1. Open Settings.
2. Choose the organization settings area.
3. Select one of the Org Settings panels from the left navigation.

How to choose a panel

1. Select Identity providers to add, edit, or remove sign-in and Domain-delegation providers.
2. Select GitHub to configure the GitHub Commit Provider.
3. Select Users to manage platform and Domain access. When Vibedata runs with ambient authentication (AUTH_ENABLED=false), the instance has a single operator; enable delegated authentication to add users. Existing users and their access remain manageable.
4. Select Capacity settings to limit concurrent Ephemeral Workspaces and driving AgentSessions, set the per-run budget, Intent and Domain retention and run-history retention, and see the observability retention and query limits.

Capacity

Vibedata Owners can set six independent limits:

• Concurrent ephemeral workspaces across Fabric and MotherDuck Domains. DuckDB Domains do not count.
• Concurrent Intent AgentSessions.
• Concurrent generic AgentSessions.
• Concurrent AgentSessions attributed to one User across both profiles.
• The maximum USD budget for one run. It applies to new Intent AgentSessions and ordinary Agent Executions. A run keeps the budget it started with. When an Agent Execution reaches the ceiling, it finishes its current step and stops further work; its failed result explains why and records usage and completed steps. A final answer that already completed stays successful. Calculated spend depends on the LLM Profile's configured rates, and the last completed step can exceed the amount. An Intent budget stop appears in chat.
• How many days to keep Completed, Closed and Archived Intents. After that period Vibedata deletes them. A deleted Intent cannot be restored. Draft, Active and pinned Intents are never removed. Before you save a shorter period, the panel shows how many Intents it would remove.

Leave a field on Unlimited when Vibedata should not apply that product limit. The two retention policies (finished Intents and Archived Domains) are the only fields with an Unlimited switch. Saving a value below current usage does not stop existing work; it prevents new work until enough sessions or workspaces finish.

Run history

The same Retention table sets how long finished run history is kept, in whole days, for each run family: bundled, custom and diagnostic Automation runs, Domain Bundle exports and imports, demo provisioning, and generic AgentSessions.

A run family with no value of its own shows the default of 7 days, labelled pg-boss default. Enter a number to override it, or select Use default to go back to the default. Run history is never unlimited — a family must keep runs for at least one day.

A change applies to runs started after you save. History already recorded keeps the period it was started with, and a scheduled run keeps the period its schedule was registered with until the reconciler re-registers the schedule.

Every user can read these settings — the limits, both retention policies, run-history retention, the warm Agent Pool, the Organization budget and the observability limits. Only a Vibedata Owner can change them. On each automation's run history you also see the period it is kept for, and whether that comes from this setting or the pg-boss default.

When interactive work reaches a limit, Vibedata names the exhausted resource and whether the instance or User limit caused it. Retry after work finishes or ask a Vibedata Owner to adjust the limit. Agent-backed Automation Runs wait in the queue instead of failing for capacity.

Observability retention and query limits

When the deployment includes the observability stack, the Capacity panel also shows Observability retention and query limits. These values are read-only. You cannot change them in Vibedata.

The panel shows the value the deployment runs with, in three groups:

• Retention: how long logs, traces and metrics are kept.
• Grafana Explore defaults: the number of log lines Grafana Explore asks for. This applies to Grafana Explore only. Loki API requests with no limit use Loki's own default.
• Datasource API defaults, ceilings and timeouts: the native limits of Grafana, Loki, Tempo and Prometheus. Each value shows its native setting name.

Vibedata's own diagnostic requests have their own, shorter deadline. Raising a timeout above does not make them run longer.

The help text tells you how to change the values for your deployment:

• Cloud deployment: These values are set by the Cloud Installer, not here. To change them, open the installation there and use Change a setting. The change restarts the observability stack and blocks logins while it runs, so plan it for a maintenance window.
• Local Docker: These values are set by the vibedata installer, not here. To change them, run vibedata compose up --observability-setting KEY=VALUE. The change restarts the observability stack.

If the deployment has no observability stack, the panel shows Observability not installed: the observability stack is not installed on this deployment, so there are no values to show. If a deployment value is not valid, the panel shows Unable to read observability settings with the error and the setting name instead of the values.

Users

Open Users to see a compact directory with names, emails, Domain counts, platform roles and pending approval or sign-in status. Select a user to open their details. The detail screen lists their Domain memberships and roles. Use Back to users to return to the directory; you can also bookmark a user's detail page.

Use Edit access on the detail screen to change platform roles or Domain access. To remove one membership, select Remove beside that Domain and confirm Remove membership. Other memberships stay in place. Existing last-owner guards still apply. Read-only viewers can inspect details without these actions.

Remove a user

User actions are checked against the individual user you reviewed. A change to that user's represented access or approval state can invalidate an open edit or removal; changing another user does not. If an action reports a conflict, reload and review the selected user before trying again. In the access editor, Discard and reload closes the old draft; reopen Edit access to make your changes against the refreshed user.

Open the user’s detail and select Delete user to delete another user. Vibedata first lists the user’s Intents, Custom Automations and the Domains they are the last owner of. For each Domain, either hand all of the user’s Intents and Automations there to one person or delete them all; platform Automations get their own row. MotherDuck Intents cannot be handed to someone else, so you choose Delete for them. For each Domain the user is the only owner of, make someone else an owner or archive it. If a new owner cannot run an Automation yet, that step fails in the progress view; fix it and select Retry. Type DELETE to confirm; Vibedata then hands over or removes that work, ends the user’s sessions, deletes their personal credentials and platform and Domain access, revokes their OAuth grants on the shared MCP connection, and removes the user. If Obot cannot confirm that revocation, the status shows residual access for follow-up. It cannot be undone. Vibedata blocks removal of the last Vibedata Owner or the last User Access Administrator. Assign the protected role elsewhere before retrying.

Approve a user who signed in

A signed-in user awaiting approval appears as Pending approval. Open their detail and select Approve to make the user valid without assigning roles. A role-less approved user appears as Valid — no access, and the detail action changes to Edit access. Select Edit access, choose the required access, and select Save changes when roles are needed.

An administrator-added user who has not signed in appears as Pending sign-in and is already approved. They need no role or Domain membership to complete first sign-in and use self-service; any assigned access becomes available after that same sign-in.

Add a user before they sign in

1. Open Users and select Add user.
2. Enter the user's verified sign-in email.
3. Optionally choose platform or Domain access. Leave every access control empty to pre-approve a role-less user.
4. Select Create user. A valid email enables Create user even without an access assignment.

The new entry is Pending sign-in and already approved. On the user's first successful sign-in, Vibedata reconciles the identity to that entry and makes the user valid. Add access later with Edit access if needed.

Add a GitHub SSO user

When GitHub is the user's sign-in provider, enter the user's verified primary GitHub email in the Email field:

1. Ask the user to open GitHub Settings → Emails and identify the address marked Primary and Verified.
2. In Vibedata, open Users and select Add user.
3. Enter that address in Email, optionally choose access, and select Create user.

GitHub accounts can have more than one email address. Vibedata uses the verified primary address when GitHub provides one; it does not match every email on the account. Without one, Vibedata uses the first address GitHub returns; if GitHub does not return an email list, Vibedata may use the profile email. These fallbacks can be secondary or unverified addresses, so do not use them to pre-provision access. If a user signs in and sees Awaiting access, compare the email shown there with the pending entry; remove the incorrect pending entry, then grant the signed-in user the intended access.

What you'll see

• Panel navigation — each Org Settings panel is shown as a left-navigation item.
• Empty state — each panel explains when no rows are configured.
• Loading — panels show loading text or skeleton rows while Vibedata fetches settings.
• Error — panels show a repair message when Vibedata cannot load the relevant settings.

MCP Catalog

The MCP catalog panel lists the supported MCP servers available to the organization. The catalog synchronizes at startup. Opening this panel reads the current catalog without starting another synchronization. While the refresh runs, the panel shows progress; if it cannot complete, it shows a retryable failure. Use Refresh catalog to synchronize manually. Select Update instances to update existing instances from the current catalog definitions.

Choose a row in Catalog to show its instances in the MCP instances tab, then select Add instance. Search either tab by any part of the name. A missing shared OAuth app is marked OAuth setup required; use the entry’s overflow menu to configure it before adding an instance.

For each catalog field, choose Preconfigured to supply a shared value, User-provided to ask each user for their value, or Ignore to omit an optional field. Required fields start Preconfigured and optional fields start Ignore. Catalog-supplied fields do not appear. Click an instance row to edit it directly. Saved choices are shown but saved values remain hidden; leave an unchanged shared value blank to keep it. Save and Cancel return to the instances list. Leaving an edited form asks whether to discard unsaved changes; choose Keep editing or Discard changes.

OAuth Clients

1. Open OAuth clients and select Add OAuth client.
2. Enter Client name and Redirect URIs.
3. Choose the optional Scopes; openid is always included.
4. Under Consent and claims, choose whether the client skips the consent screen and which claims its tokens carry.
5. Select Create.
6. Copy the Client secret immediately; it is shown only once.

Open a client by selecting its name or choosing View details from its row menu. Its page shows the saved client name and has its own URL. Use Rotate secret there to issue a new secret and invalidate the previous one. Copy the new secret before closing the reveal or leaving the page; it is not shown again after navigation or reload. Delete remains available in the row menu when you have permission. Review the confirmation before continuing. A loading message appears while the list loads; a failed load offers Retry.

OAuth-client rotation and deletion also retain the individual client you reviewed. If the client changes before confirmation, reload and review it before trying again; an older review is not automatically retried against the new client.

Connector Sources

Vibedata Owners can use Connector sources to manage public repositories that supply connector code. Each row shows its name, repository and branch, and Last updated, the time of its last successful refresh. Before the first successful refresh, it shows Not updated yet. A failed refresh adds Refresh failed, the last attempt time, and the error; it keeps the last successful update time visible.

Add a repository

1. Select Add repository.
2. Enter a stable lowercase name containing letters, numbers, and hyphens.
3. Enter the repository in owner/repo, owner/repo#branch, or full HTTPS Git URL form (for example, dlt-hub/verified-sources). Specify the branch inline after # or in Branch or tag (defaults to main).
4. Select Test connection in the footer.
5. After the test passes, select Create. Changing the repository or branch requires another test.

Registration does not ask for credentials or clone the repository immediately.

Edit a repository

Select a custom source's row, or choose Edit source from its … menu. The name cannot be changed. Change the repository or branch, select Test connection in the footer, then Save after it passes. Cancel discards your changes and reloads the saved configuration.

The Test button at the top tests the saved configuration. It is disabled while you have unsaved changes. It does not test the unsaved draft or enable saving a changed connection. The official source opens read-only.

If the source changes while you edit it, reload and review the latest values before trying again. Saving a different repository or branch clears the old refresh result; Last updated then reflects successful refreshes of the new configuration.

Refresh or delete a repository

Choose Refresh source from a row's … menu to refresh it immediately. This runs the same operation as the hourly Connector source cache refresh Maintenance job. Open Maintenance jobs, select Connector source cache refresh, and inspect a run to see each repository's refreshed, unchanged, failed, or skipped outcome. An unchanged successful refresh also advances Last updated.

Choose Delete source from a custom source's … menu and review the confirmation before removing it. Cancel the confirmation to keep the source. The official source has no edit or delete action. A failed delete keeps the confirmation open and shows the error. A background refresh can change the source while you review it; reload and review it before retrying a conflicted deletion. Deletion removes the registration and cached clone; later refresh runs no longer include that source.

LLM Profiles

Vibedata Owners can open Org settings → LLM profiles to configure the models available to Vibedata agents. In Profile name, enter 1–64 characters: start with a letter or number, and use only letters, numbers, periods, underscores, and hyphens. Names cannot end in .json. Invalid typed or pasted characters are rejected.

Vibedata supports up to 50 LLM Profiles. At that limit, existing profiles remain editable, but you must delete a profile before creating another.

When creating a profile, open Provider and type any part of a provider label to filter the choices, regardless of letter case. Named providers are alphabetical, with Custom (OpenAI-compatible) last. Filtering does not change your selection or add a provider; choose a listed option. Provider cannot be changed on edit.

Choose the model

For Amazon Bedrock, the form asks only for a Region instead of an API key and Base URL. Vibedata reaches Bedrock through one IAM role in your AWS account, set once for the whole deployment under Amazon Bedrock access on this page: create a role whose trust policy lets the Trusted principal shown there assume it and requires the External ID shown there (see the example below), give it permission to invoke your models and to list Bedrock foundation models and inference profiles, then enter its Role ARN and save. Vibedata checks the role before saving it: the role must refuse an assumption without the External ID and accept one with it. No access key is stored, and every Bedrock call uses short-lived credentials from the role. You can replace the role but not remove it. Until a role is saved, Bedrock profiles cannot be created, tested or listed. If a Domain's default profile is Bedrock, the Domain repository's design-drift check cannot run and reports a failure, because that check only works with providers it can call in the OpenAI style — with or without a key. If you are switching a Domain from another provider, delete the old LLM_API_KEY secret from the repository, since Vibedata does not remove it; the check will not send it to Bedrock, but it has no reason to stay. For every other provider, enter the API key and Base URL first: Model loads its list from the provider at that Base URL when you open it, and says which of the two is missing until both are present. The list shows 25 models at a time; type any part of a name to search the rest. To use a model the list does not show — an Azure deployment name, a gateway alias, or a model beyond the loaded list — type its id and select Use model id: your-id. Custom (OpenAI-compatible) has no list, so you always type its model id.

A trust policy for the Bedrock access role, with the two values copied from Amazon Bedrock access. Every session Vibedata starts names a source identity and a session tag, so the policy must allow sts:TagSession and sts:SetSourceIdentity as well as sts:AssumeRole:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "<Trusted principal>" },
      "Action": ["sts:AssumeRole", "sts:TagSession", "sts:SetSourceIdentity"],
      "Condition": { "StringEquals": { "sts:ExternalId": "<External ID>" } }
    }
  ]
}

If Trusted principal says the deployment has no AWS identity, the deployment was installed without one and Bedrock cannot be used until it has one. If it says the role's path could not be confirmed, Vibedata only knows the role's name: if that role has an IAM path, insert it after role/ (for example arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/ap-southeast-1/AWSReservedSSO_Admin_0123456789abcdef), or ask whoever installed Vibedata for the role's full ARN.

Canonical model names the model your profile actually runs, so Vibedata knows its price, context window and capabilities even when the model id is a deployment name or an alias. For most providers it is filled in for you and read-only; for Azure Foundry it is the model your deployment serves. An Azure deployment that is not in the list reads — resolved when you save. For Custom (OpenAI-compatible) and Ollama, open Canonical model, type part of the model's name to search the catalogue, and select the matching entry, or None — not in the catalogue if there is none.

Snowflake Cortex

For Snowflake Cortex, the Base URL is your account URL, such as https://<org>-<account>.snowflakecomputing.com; Vibedata adds the API path itself. The API key is a Snowflake programmatic access token (PAT). Paste the token itself; a pat/ prefix is also accepted. Model lists the Cortex chat models your role can use, by their lowercase names such as claude-sonnet-4-5. If the list is empty, ask a Snowflake account administrator to grant your role access to the models, or to run CALL SNOWFLAKE.MODELS.CORTEX_BASE_MODELS_REFRESH(). Key-pair and OAuth sign-in are not supported.

Values filled from the catalogue

The canonical model fills the input and output cost, context window, native tool calling, and the model capabilities. Under each filled field, a note shows where its value came from:

Note	Meaning
From catalogue · canonical-model	The value comes from the catalogue entry for your canonical model.
Set by you	You changed the value. It is kept when the catalogue changes or you pick another canonical model. Select Reset to catalogue to go back to the catalogue value.
Runtime default — …	The field is empty and is not sent; the model runtime decides. The note says whether there is no canonical model or the catalogue has no value.

Clearing a field the catalogue fills also returns it to the catalogue value. Cost is always editable: the catalogue holds list prices, so enter your contract or gateway price if it differs. An Ollama model's cost starts at 0, because it runs on your own hardware. A profile with no cost and no catalogue price shows Needs price in the profile list and cannot run until you enter its cost.

Cost estimates use the selected profile's input, output, cache-read and cache-write prices. Configured off-peak prices apply to calls that complete during an off-peak window; calls outside it use the regular prices. When no separate cache price is configured, cached tokens use the regular input price.

Context window is required. For a model the catalogue knows, it is filled in for you. For a model it does not know, or lists with a window smaller than the runtime accepts (16,384 tokens), enter the window yourself: the profile cannot be saved until you do, and the field says so. A profile saved before this rule that holds no window shows a Needs context window status in the profiles list. It keeps running, but only compacts long conversations by event count, so edit it and set a window.

Model capabilities

Open Model capabilities to see what Vibedata tells the model runtime this model supports: vision, reasoning effort, prompt caching, the Responses API, thinking mode, sampling parameters, stop words, and cache retention. A capability the catalogue knows about offers Supported or Not supported, with its source note. The others stay at Runtime default until you choose a value. Change a value only when you know the model behaves differently from what the catalogue says; whatever the profile shows is what the runtime receives.

Google Cloud Vertex AI

Choose Google Cloud Vertex AI to run Gemini and partner models served by Google (such as DeepSeek or Llama) in your own Google Cloud project. There is no API key or Base URL to enter: Vibedata signs in as a Google service account you name.

By default no credential is stored. Vibedata obtains short-lived tokens for the service account from its own deployment identity:

1. In Google Cloud, create a service account in the project that pays for the calls, and grant it the Vertex AI User role (roles/aiplatform.user) on that project.
2. On that service account only, grant Vibedata's deployment identity the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator). The form names both roles to grant. Your administrator knows Vibedata's deployment identity; Vibedata does not display it.
3. In Project ID, enter the Google Cloud project.
4. In Location, choose the region that serves the model, or global.
5. Under Authentication, keep Impersonate a service account (recommended).
6. In Service-account email, enter the service account's email.
7. Discover or type the model, for example gemini-2.5-pro or deepseek-ai/deepseek-v3.1-maas. Test the connection, then save.

Saving is refused until Vibedata has obtained a token as the service account. A new grant can take a minute or two to take effect, so a save straight after granting may wait before it succeeds. A service account that a Domain's BigQuery connection already uses cannot be named.

If your organisation cannot grant the Token Creator role, choose Service-account key under Authentication instead, and paste the JSON key or choose Upload .json. The key must belong to the service account you named. It is stored encrypted and never shown again, and the profile shows an advisory recommending keyless sign-in. For a key-backed profile, changing the project, location or service account requires pasting the key again; switching the profile to keyless removes the stored key.

Claude models on Vertex AI are not offered; use the Anthropic provider for Claude.

Vertex AI in Domain CI

When a Vertex AI profile is the default, each Domain repository's ci/design-drift check calls the same model. It signs in without a key: the GitHub workflow exchanges its own short-lived identity token through a Google Cloud workload identity provider, then impersonates the profile's service account for one hour. No key is written to the repository, whichever Authentication method the profile uses.

To enable it:

1. In Google Cloud, create a workload identity pool and an OIDC provider for GitHub (https://token.actions.githubusercontent.com). Add an attribute condition that admits only your Domain repositories, by owner and repository id, and only pull requests into main: assertion.repository_owner_id == '<owner-id>' && assertion.repository_id in ['<repo-id>'] && assertion.event_name == 'pull_request' && assertion.base_ref == 'main'. Do not require refs/heads/main: the check runs on pull requests, so that condition refuses every run.
2. On the profile's service account, grant each Domain repository the Workload Identity User role (roles/iam.workloadIdentityUser), using the principalSet for its attribute.repository_id rather than one for the whole organisation. This is a separate grant from the Token Creator role Vibedata itself uses.
3. In CI workload identity provider, enter the provider's resource name: projects/<number>/locations/global/workloadIdentityPools/<pool>/providers/<provider>. Save the profile.
4. Run /install-ci in each existing Domain repository so its workflow picks up the sign-in step. A repository installed afterwards has it already.

Until the field is set, the Domain's CI values report the provider as not captured, and the design-drift check fails with a message asking you to set it.

Test a saved LLM profile

Select a profile name to open its page, or use Edit from its list row. The page title is the saved profile name, and its URL can be opened directly. Select Test to test the saved configuration and read the result on this page. Save or cancel draft changes before testing the saved configuration. Tests required while creating or editing a connection remain part of the form and gate Save.

How to set LLM execution behavior

1. Open Org settings → LLM profiles.
2. Create a profile or select Edit on an existing profile.
3. Open Advanced execution settings.
4. Set Temperature, Max output tokens, and Reasoning effort as needed.
5. If prompted, select Test connection. After it succeeds, select Create for a new profile or Save for an existing one.

Leave Temperature or Max output tokens empty to Use default. Select Use default for Reasoning effort to let the model and provider choose their default behavior.

Control	Accepted value
Temperature	A number from 0 to 2, in steps of 0.1, or Use default.
Max output tokens	A whole number of 1 or more, or Use default.
Reasoning effort	Use default, Off, Low, Medium, High, or Extra high.

These values belong to the shared LLM Profile. Intents select a profile but do not have separate execution-setting controls. An AgentSession that is already running keeps the profile values it started with; Pause the Intent, then open it again, to apply a saved profile change to that session.

Preview features

Open Org settings → Preview features to try features that are not ready for every install. Each preview feature has a switch that takes effect immediately and can be turned off again. Most start off; Landlocked Agent Server starts on, and turning it off applies to agent containers started afterwards. Features marked Upcoming are listed without a switch and cannot be turned on yet. Only a Vibedata Owner can change these switches.

Credit packs

Open Credit packs to review credits on deployments that enforce marketplace licensing. Credits are drawn from packs with the oldest expiry first.

• Packs lists purchases and their remaining credits.
• Credit usage shows consumption.
• Buying contains Buy automatically, Buy when balance falls below, Packs per purchase, and Monthly cap. Changes require permission to manage credit packs.
• Statement shows balance movements, including the opening and closing balance.

Review the warnings above the tabs when a purchase or the available balance needs attention.

Usage analytics

Open Usage to review consumption across the instance. Budget standing opens first and reports the current calendar month, whatever window is selected below it. It leads with a sentence saying where the current pace leaves you — the rate, where that lands by month end, and whether that is inside the configured limit — then states spend to date, burn rate and the projected total. With a budget configured it reads On track, Near limit, or Exhausted, and shows either the remaining headroom or how far spend is over the limit; an exhausted budget offers a Raise the limit link. With no Organization budget configured it reads No monthly budget set — spend is unlimited and offers a Set a limit link. Both links go to Capacity settings' Budgets tab.

The Intent ledger reports the selected window, listing every Intent with recorded spend in it, sortable by Cost, Turns, or Last active, and paged. It is open by default, and collapses to a count of the Intents it covers.

Cost by LLM profile reports the same window as one row per profile: the model it mostly ran, the sessions and turns it took, the tokens it consumed and how those divided between new input, output, cache and reasoning, and what it cost. It is collapsed by default, and says while collapsed which profile leads and by how much of the window's spend.

Choose Last 7 days, Last 30 days, or Last 90 days — the page opens on the last 7 days, and every section except Budget standing follows that choice. Estimated cost uses the configured LLM profile rates. Read any attribution notice before interpreting totals; missing attribution can affect their coverage. There is no refresh control: the page reads a durable ledger that is always current, so reloading shows the same figures. If loading fails, select Retry.

A Domain's own Usage tab shows the same panel scoped to that Domain and its own budget; see Domains → How to review Domain usage.

Audit records

Open Audit records to review security-relevant actions. Narrow the list with Time, Actor, Action, Outcome, Resource type, and Resource IDs. Select a record to inspect its details. Use Refresh to reload or Export JSON to export the displayed results.

The panel shows the available retention and coverage. An empty result describes the selected time range and filters; adjust them to search again. When the audit log is unavailable, follow the panel's recovery message.

Archive

Open Archive to see the records that the Immutable billing and audit archive job copied to protected storage. Nobody can change or delete these records. Only a Vibedata Owner on a deployment with protected storage sees this section; everyone else is offered neither the link nor the page. A deployment without protected storage has nothing to read, so the section is absent and the Archive API answers 409 rather than an empty archive.

1. In Records, choose AI spend, Credit pack purchases, or Audit records. The same access covers all three kinds.
2. Choose a From and a To day. The range can be at most 90 days, and To cannot be after today.
3. Read the records in the table, 100 rows per page.
4. Select Export beside the page title to download them as a CSV file. Export is unavailable when the range holds no records, since there is nothing to save.

The table and the CSV file hold the same records and the same columns. Nothing is grouped or left out.

• AI spend has one row per AI turn, with its model, tokens and cost.
• Credit pack purchases has one row per pack, as it was when it was copied, with its purchase, terms and billing fields.
• Audit records has one row per audit record.

If a read or an export fails, the page shows the reason.

Maintenance jobs

Open Maintenance jobs for the list of bundled automation jobs, grouped under Platform, Per domain, and On demand. Each row shows the job's description, then its schedule in words with the timezone (for example Every hour on the hour (UTC)). Select a job to open its page, which contains Schedules and Runs, with Run now in the header when you have permission. Use Filter runs by status to narrow its history, then select a run to open its details. Use Back to maintenance jobs to choose another job. Diagnostic queries (mine), under On demand, opens your own query history. A job that runs for more than one Domain appears once per Domain, named by the Domain it belongs to. An on-demand run is queued and reported on the job's page, where View run opens its result once the run is identified.

These are bundled jobs rather than your Custom Automations. Their schedules are fixed and cannot be changed. See Custom Automations for running jobs, changing the schedules of your own automations, and reviewing or cancelling runs; the available actions depend on your access and the job.

Related

• Data Platforms
• Identity Providers
• GitHub
• Settings Overview