Admin

The Admin area in the console holds the controls that apply to your whole organization, not to a single namespace. You’ll typically configure these once during onboarding and revisit only when something changes.

​

Members

The Members page lists everyone with access to your organization. It has two halves:

• Active members — people who have accepted an invitation and signed in
• Pending invitations — invites sent but not yet accepted (with their expiry date)

​

Roles

Every active member has a role that determines what they can do across the console. For finer-grained access than the role gives, grant individual namespaces from the namespace’s permissions panel. The two systems compose — a member with no grants sees nothing namespace-specific; a member granted read access on ns_a sees that namespace.

​

Inviting

Click Invite and provide an email address and role. The invitee receives a sign-in email and creates an account on first sign-in. Pending invitations expire after the WorkOS-configured TTL.

​

Changing roles

An admin can change another member’s role from the kebab menu. The change is applied immediately and audited.

​

Removing

Click Remove to revoke access immediately. The user keeps their personal account but loses access to anything in your org, including any namespace grants.

​

Ontology

An ontology is the schema your extractor uses during remember — the entity types it should look for and the relationship types it should connect them with. Defaults are general-purpose (PERSON, ORGANIZATION, CONCEPT, LOCATION); domain work usually wants more specific types.

​

Creating an ontology

You can ship an ontology with no types and add them later, or define everything up front.

​

Editing an ontology

The detail view supports adding, renaming, and deleting entity types and relationship types after creation. Each change is audited. Renaming a type does not rewrite past extractions — only memories ingested after the change pick up the new name.

​

Picking which ontology runs

Three places you can set this:

1. Org default — the ontology marked is_default. Used by every namespace unless overridden.
2. Namespace default — set per-namespace from the namespace detail view. Overrides the org default for that namespace.
3. Per-call override — pass ontology_id on a remember call to pin extraction for that specific document.

​

Deleting

Delete an unused ontology from the kebab menu. You cannot delete the org default — promote another ontology first.

​

Plugins

Plugins are inbound webhook receivers — they let an external service push events to Deyta Platform. The current supported provider is workos, used to receive WorkOS directory-sync and user-management events so changes in your IdP propagate into the console automatically. When you create a plugin, Deyta Platform issues you:

• A webhook URL unique to your org (a long, random path on api.deyta.ai). You configure the upstream provider to POST events to this URL.
• A signing secret that you also configure on the upstream provider. Deyta Platform validates each incoming webhook against this secret to confirm it really came from your provider.

​

Event history

Each plugin has a paginated events view showing every webhook the upstream provider has delivered. Useful for verifying delivery, diagnosing signature mismatches, and replaying events during integration work. Events show:

• External event ID (from the provider)
• Event type
• Status (received, processed, failed)
• Error message if processing failed
• Received and processed timestamps

​

Limits

One plugin per provider per org. Today this means one workos plugin — additional providers will land as new plugin types. Toggling a plugin to inactive stops processing without deleting its history; deleting the plugin removes both the receiver and the event history.

​

Integrators

Integrators are the data-source providers your org has enabled for use in integrations. Common providers: Google Drive, Snowflake, object stores. For each provider you can:

• Enable / disable at the org level — disabled providers are hidden from the integrations UI and start calls return 403
• Configure provider-specific credentials if the integration uses an org-wide service account rather than per-user OAuth

Toggling a provider off does not disconnect existing connections; it only prevents new ones from being created.

​

Audit log

Every state-changing action in the console and the API writes an entry to the audit log. Filter by:

• Time range
• Actor (user email or API key)
• Action (namespace.created, memory.remembered, data_source_connection.connected, etc.)
• Entity type / ID

The audit log is read-only and append-only. Entries are retained per your organization’s plan.

​

Domains

If your organization uses email-domain-restricted SSO, configure the allowed domains here. Users signing in with an email outside the allowlist are denied access to your org. This is independent of WorkOS-level SSO configuration; it’s an extra check applied by Console at sign-in.

​

What’s next