Administration and Security

Audit logs

How Ottili ONE records what happens in your company: company-scoped, traceable audit logs across modules and services, what an entry contains, and who is allowed to view them.

Overview

Ottili ONE keeps a record of what happens in your company. Important, security-relevant actions are captured in audit logs* across modules and services — traceable, company-scoped, and designed so they cannot be silently changed. Together with deny-by-default access control and strict tenant isolation, this produces a complete, auditable trail across the whole platform.

This article explains what audit logs are, what a single entry contains, where they apply, and who in your company is allowed to view them. Deeper articles are listed at the end under [Related articles](#related-articles).

What are audit logs?

An audit log is the platform's chronological, tamper-evident memory for security-relevant events. Instead of every service keeping its own isolated log, Ottili ONE writes auditable events into shared, company-scoped audit records. The result is one consistent trail across every module: Business Hub, LD3, Ottili Files, Flows, Coder, Messenger, Support and the platform services themselves.

The ground rule: every checked, mutating or security-relevant action leaves an entry.* A denied or failed access is logged just like a successful one — so an attacker or an accidental mistake always leaves a trail.

What is in an audit entry?

An audit entry describes the event with the fields needed for traceability. Using the module access audit as an example, these include:

Timestamp:* when the action took place.
Requesting module:* which service triggered the action.
Target module:* which service the action concerned.
Access type:* the kind of access (e.g. read or write).
Operation:* the concrete action (e.g. install, activate).
Status:* the outcome of the action (success, denied, error).
Capability required:* which entitlement/permission was checked.
Reason:* a short explanation, e.g. for a denial.
Company (company_id):* the verified tenant boundary the entry belongs to.

Not every audit log carries all of these fields — depending on the source (module lifecycle, entitlement checks, secrets access, Messenger, Support) the relevant security fields are captured. What matters is that every log is tied to exactly one company and carries enough context to reconstruct the action later.

Where audit logs apply

Audit logs currently cover at least these areas:

Module lifecycle:* installation, activation, deactivation, uninstallation, and health-status or upgrade changes are written as audit events.
Permissions and entitlements:* every denied entitlement check is recorded as an audit event — who, when, on what, and why it was denied.
Secrets management:* administrative secrets access is logged for traceability; sensitive values are masked.
Messenger actions:* messaging and bot actions are written to the platform's central audit table.
Support:* every mutating support action emits exactly one append-only audit event, so the history cannot be altered.
Tenant isolation:* isolation checks leave a comprehensive audit trail; every confirmed context check is recorded.

Company-scoped and isolated

Audit logs are just as company-scoped as the rest of the platform. Every entry carries a verified company_id; cross-company access is never inferred from a default, a first membership, or a caller-supplied value.

Fail-closed:* the shared assert_same_company() primitive rejects any request with no or mismatched company context.
Database row-level security (RLS):* queries against audit tables are filtered by the verified company_id; the runtime default is deny.
No cross-tenant:* one company can never read another company's audit logs.

This means audit logs prove not only what happened, but that it happened inside the correct tenant boundary.

Who can view audit logs?

Access to audit logs follows the same explicit, deny-by-default logic as the rest of Ottili ONE. Sensitive visibility is tied to roles:

Owner and Admin:* hold the broadest rights and see their company's security-relevant events through Observability and the Ottili Console* ([ottili.one/console](https://ottili.one/console)).
Manager, Employee and Viewer:* receive only the visibility their role explicitly allows — never the full audit history without permission.

The Console and Observability share the same Ottili Auth login and the same company context; anyone without permission sees no entries. How roles decide this in detail is described in [Roles and permissions](/docs/roles-and-permissions).

Status and availability

Ottili ONE clearly distinguishes between Live, Beta, Private Beta, In Development, Planned and Concept. For audit logs, the current state is:

Live:* logging of security-relevant actions (module lifecycle, entitlement denials, secrets access, Messenger actions, support events, isolation checks) is an active part of the platform.
Live:* administrator visibility is provided through Observability and the Ottili Console.
Live:* the company-scoped, append-only design ensures logs cannot be altered after the fact.

We deliberately do not claim not-yet-verified features (such as exported, cross-cutting audit dashboards) as available. What the status terms mean in detail is described in [Understand feature status labels](/docs/understand-feature-status-labels).

[Security overview](/docs/security-overview) — how the security architecture fits together.
[Roles and permissions](/docs/roles-and-permissions) — who can see and do what.
[Approval Queue](/docs/approval-queue) — human approval for sensitive actions.
[Tenant isolation](/docs/tenant-isolation) — why your data and logs stay isolated.
[Shared permissions and entitlements](/docs/shared-permissions-and-entitlements) — the cross-cutting permission model.
[Company, team & permissions](/docs/company-and-team) — how roles and access work.
[Account and data security](/docs/account-and-data-security) — authentication, sessions, isolation, reporting a vulnerability.
[Navigate the Ottili Console](/docs/navigate-ottili-console) — where to find administration and Observability.
[Understand feature status labels](/docs/understand-feature-status-labels) — what the status terms mean.

Was this article helpful?