Overview
Hatz provides tools to review activity in your account through audit logs (administrative actions) and usage activity (workspace usage patterns).
Quick guide: Use Audit events for administrative and security-relevant events, Invocation logs for high-level usage metadata, and Invocation content only when the organization setting and manage-level compliance permission both allow full session or workflow content access.
Administrators can control who can access different levels of information, from high-level event records to full conversation content.
This documentation explains how compliance visibility works, what organization settings control access, and which role permissions are required for each layer of information.
Organization Settings: Enabling Visibility
Administrators control compliance features through organization-level settings. These act as master switches - if a setting is disabled, no user can access that layer of information for that organization, regardless of their role permissions.
These apply per tenant. If a switch is off, that kind of data is not available for that tenant, regardless of user role (except where noted below).
The available controls can vary by workspace and rollout. The Audit Event IP Addresses control appears with the other compliance visibility settings when available.
Setting | When on | When off |
Audit events view | Users who have permission to view audit data for this tenant can open the audit log for this tenant. | No one can view audit events for this tenant through compliance. |
Audit Event IP Addresses | When Audit events view is also on, eligible viewers can see a recorded actor IP in audit-event details and in the | Actor IP addresses are hidden from audit-event responses, details, and exports for this tenant. |
Invocation logs view | Users who have permission to view invocations for this tenant can see high-level invocation rows (metadata such as time, user, model, agent, source, etc.—not full message bodies). | No one can use the invocation list for this tenant. |
Invocation content view | Users who have both the tenant invocation content setting on and manage-level compliance permission for that tenant can see extra detail (see Invocation content below). | Invocation content (full chat messages, workflow step payloads, chat file lists, compliance file download, etc.) is not available. The invocation list may still be available if Invocation logs view is on. |
If your organization has never saved settings, the product uses these defaults:
audit viewing on, Audit Event IP Addresses off, invocation list off, invocation content off.
Changing these settings will notify administrators.
Audit log
Who can open it: anyone with view or manage compliance log permission for that tenant, and Audit events view is on for that tenant.
What each entry shows: time, event type (with a display name where configured), tenant name and external id (as stored on the event), actor (signed-in user with email and public user id, or system), optional target and extra details depending on event type. When Audit Event IP Addresses is on, an entry can also show the actor IP recorded for that request.
An IP address may be unavailable for older events, system-generated events, database-generated events, or requests where the trusted application edge could not determine an address. Turning the setting on reveals IPs that were recorded; it does not backfill missing historical values.
Registered event types the product can record include: successful sign-in, MFA verified, API key created, API key deleted, chat deletion scheduled, compliance file downloaded, file deletion scheduled, compliance export triggered, compliance export downloaded. Your workspace may not show every type if that activity has not occurred.
Event Types Include:
Invocation list vs invocation content
Invocation list (needs Invocation logs view on and view or manage invocation permission): rows derived from usage records—who, when, tenant, user, agent, model, source, links to session/app where applicable, etc. Not full conversations by default.
Invocation content (needs Invocation content view on and manage compliance logs permission for that tenant):
In the list, session names (chat / app / phone labels) are shown only when the viewer has manage compliance access and passes the content check for that tenant.
On invocation detail with content requested:
Chat: full saved message history for that chat and a list of files tied to that chat (name, type, size, status; download uses the compliance file flow).
Workflow: workflow step-run records for that job and files tied to that workflow run.
Other sources: this path does not attach message history or workflow step payloads; you still see whatever metadata the list/detail returns for that row.
Turning the setting on is not enough — the role matters too. Invocation content view only unlocks full transcripts at the tenant level. To actually open them, an admin must also have a role that includes Manage Compliance for that tenant.
Partner / MSP admins: only Primary Admin and Compliance Manager can open full transcript content. A regular Admin can browse the invocation list (metadata only) but will not see full chat messages, even when the setting is on.
Customer-side admins: this needs the manage_own_entity_compliance_logs permission. The default Client Admin role does not include it, so it must be granted through a custom role.
If you can browse the activity list but every transcript looks empty or locked, check the role first — not just the setting.
Available Settings
Setting | If Disabled |
Audit log visibility | No one can access the audit log for that organization |
Audit Event IP Addresses | Recorded actor IP addresses stay hidden in audit-event details and CSV exports |
Invocation / activity visibility | No one can browse activity lists for that organization |
Invocation content visibility | No one can open full session content, even if they can see activity metadata |
Who Can Change These Settings
Only users whose role includes "manage compliance settings" permission can enable or disable these organization-level switches. Please see below for a more detailed breakdown. This applies to:
Partner administrators managing customer organizations
Customer administrators managing their own organization
Change Notifications
When compliance settings are modified, appropriate administrators (others who manage compliance for that organization) may be notified to ensure changes are not made silently.
Roles and Permissions
Capability | What It Allows |
View audit logs | Open and search the audit log for allowed organizations (when audit visibility is enabled) |
View invocations | See invocation and usage lists (metadata only) when that visibility is enabled |
Manage compliance | Full compliance access including everything "view" permissions provide, plus opening invocation content (when enabled) and performing compliance officer tasks like exports |
Manage compliance settings | Change organization compliance switches (enable/disable audit logs, invocation visibility, and content visibility) |
Admin Role Capabilities
Admin Role | View Audit Logs | View Invocation Logs | Manage Compliance Logs | Manage Compliance Settings |
primary_admin | Yes | Yes | Yes | Yes |
admin | Yes | Yes | No | No |
compliance_manager | Yes | Yes | Yes | Yes |
tenant_manager | No | No | No | No |
billing_manager | No | No | No | No |
helpdesk | No | No | No | No |
End Customer Role Capabilities
Values below reflect the default role-to-permission mapping in the product configuration. Your account may differ if using custom roles.
End Customer Role | View Own Organization Audit Logs | View Own Organization Invocation Logs | Manage Own Organization Compliance Logs | Manage Own Organization Compliance Settings |
Client Admin | Yes | Yes | No | Yes |
General User | No | No | No | No |
Workshop User | No | No | No | No |
Chat Only User | No | No | No | No |
End Customer Custom Role Permission Capabilities
These permissions are set for custom user roles in the end customer tenant.
Permission name | What it does |
| Lets customer-side users view audit log events for their own organization only. |
| Lets customer-side users view invocation/activity log entries (non-content level) for their own organization only. |
| Customer-side full compliance-log management for own organization; includes elevated compliance actions in own scope. |
| Lets customer-side users control compliance visibility settings for their own organization only. |
Exports
Audit events and invocations can be exported where the product exposes export (for example CSV), subject to size limits enforced by the product.
Export actions require the same class of access as viewing that data (audit read permissions for audit export; invocation read permissions for invocation export).
A successful export download can be recorded as an audit event (so exports are traceable in the audit log).
Legal, retention, and certifications
Do not infer retention periods or legal obligations from this page. Point readers to your official Trust / Security, DPA, or equivalent documentation for retention, subprocessors, and certifications.
Limitations
What Audit Logs Do Not Include
Audit logs record specified administrative and security-relevant events, not every technical action in the system
The specific events captured are defined by the product
Audit logs are not real-time monitoring tools - there may be processing delays
Access Control Boundaries
Organization settings override role permissions - even users with powerful roles cannot access disabled features
Data Retention
Log and session data retention follows your subscription terms and product data practices
Retention periods are defined in your agreement or trust documentation, not in the product UI
Historical data availability depends on your plan and when features were enabled
Compliance and Legal Obligations
Hatz compliance tools help govern access and review activity, but do not replace your organization's policies or legal obligations
Compliance settings should align with your data governance and privacy requirements