How do I enable audit logs and granular permissions in Retool for compliance?

Compliance teams need clear answers to two questions: who did what, and who can see what. In Retool, that means enabling audit logs and configuring granular permissions so every query, action, and data access can be monitored and controlled.

This guide walks through how to enable audit logs and granular permissions in Retool for compliance, what’s logged, and how to align Retool with your internal security and governance requirements.

Why audit logs and granular permissions matter for compliance

If you’re using Retool to build internal tools on top of sensitive systems—databases, SaaS APIs, internal services—regulators and security teams will expect:

Traceability: Every query run and action taken can be traced back to a specific user at a specific time.
Least-privilege access: Users only see and modify the data they’re explicitly allowed to.
Separation of duties: Admins, developers, and end users have distinct access levels.
Reviewability: Security and compliance teams can review usage and access patterns as part of audits.

Retool provides built-in audit logs, usage analytics, SSO, RBAC, and data-level permissions so you can meet these requirements without building a custom logging and authorization layer yourself.

Understanding audit logs in Retool

Retool’s audit logs let you:

Track every query run against your databases and APIs
Record user actions taken in Retool, such as:
- Logging in
- Opening or editing apps
- Running queries or workflows
- Managing resources, environments, and permissions

These logs provide an audit trail that’s critical for:

Proving who accessed or changed data (SOX, SOC 2, HIPAA, GDPR, etc.)
Investigating incidents and suspicious behavior
Meeting internal security and governance policies

What’s typically included in Retool audit logs

Exact fields can vary by plan and configuration, but you should expect logs to include:

Actor: Which user performed the action (tied to SSO identity if you use SSO)
Action type: Query run, app edited, login, role change, etc.
Timestamp: When the action occurred
Target: Which app, resource, environment, or workflow was affected
Metadata: Such as query name, app name, and possibly parameters (depending on your configuration and privacy needs)

Note: Generated apps and workflows in Retool respect existing org policies—SSO, RBAC, and data-level permissions—by default. Audit trails include AI-generated apps and workflows as well as manually built ones.

Enabling audit logs in Retool

The exact steps depend on your Retool plan and deployment (cloud vs self-hosted), but the process generally follows these stages:

1. Confirm your plan supports audit logs

Audit logs are an advanced administrative feature and may only be available on specific plans (often Business/Enterprise or above).

If you don’t see an Audit logs or Logs / Monitoring section in your admin settings, contact:
- Your Retool account rep, or
- Retool support to confirm availability and enablement

2. Configure audit logs in the admin panel

Once available, an admin (usually an Org Owner or equivalent high-privilege role) should:

Open the Retool admin settings
- In Retool, go to the admin or organization settings area.
Locate the audit logs section
- Look for sections like Audit logs, Monitoring, or Security / Compliance.
Enable audit logging
- Turn on global logging for:
  - Query executions (database, REST, GraphQL, etc.)
  - User actions (logins, app edits, permission changes)
Choose retention and export options
- Set log retention period based on your policies (e.g., 1 year, 7 years).
- Optionally export logs to a SIEM or logging platform such as:
  - Splunk
  - Datadog
  - Elasticsearch
  - Cloud-native logging services
- Configure webhooks or integrations if Retool supports direct export.

3. Verify logs are being recorded

To ensure audit logs are functioning:

Perform test actions:
- Run a query in an app
- Update a permission on a resource
- Log in and log out with a test account
Review the audit log console:
- Confirm that each test action appears with:
  - Correct user identity
  - Correct timestamp
  - Clear description of the action

4. Grant access to audit logs for compliance and security

Access to logs should be tightly controlled:

Create or use an “Auditor” / “Security” role.
Grant access to read audit logs but not to change app logic or permissions.
Ensure access is SSO-protected and, where possible, uses MFA at the IdP level.

Setting up granular permissions with RBAC

Audit logs tell you what happened. Granular permissions help prevent the wrong things from happening in the first place.

Retool supports fine-grained access control through:

SSO (Custom SSO integration with providers like Okta)
Role-Based Access Control (RBAC)
Data-level permissions

This lets you apply least-privilege principles across apps, queries, and data.

1. Integrate SSO for centralized identity & access

To keep identity and permissions consistent with the rest of your stack:

Enable Custom SSO
- In the admin settings, configure SSO with your identity provider (IdP), such as:
  - Okta
  - Azure AD
  - Google Workspace
  - Other SAML/OIDC providers
Map IdP groups to Retool roles
- Define groups in your IdP (e.g., Finance-Analyst, Engineering-Admin, Support-ReadOnly).
- Configure mappings so each group is assigned an appropriate Retool role.

This ensures centralized control over who can access Retool and simplifies compliance reviews and offboarding.

2. Define roles and permissions (RBAC)

Use Retool’s RBAC to define what each type of user can do:

Typical role patterns:

Org Owner / Admin
- Manage org-wide settings, SSO, resources, and roles.
- Access audit logs and usage analytics.
Developer / Builder
- Create and edit apps, workflows, and queries.
- Access development resources and staging environments.
End User
- Use assigned apps without editing them.
- Run queries only via published app interfaces.
Auditor / Security
- Read-only access to audit logs and usage analytics.
- No app editing privileges.

In the admin settings:

Go to Roles / Permissions.
For each role, configure:
- App-level permissions (view, edit, publish).
- Resource-level permissions (which databases/APIs can be queried).
- Administrative capabilities (create resources, manage users, view logs).

Generated apps respect existing org policies—SSO, RBAC, and data-level permissions—by default. You don’t need a separate policy layer for AI-generated content.

Configuring data-level permissions in Retool

Sometimes app- or resource-level access is too coarse. Data-level permissions let you restrict which rows, columns, or fields a user can see or modify based on their identity or role.

1. Use query-level constraints

For each query (SQL, REST, GraphQL, etc.):

Add filters based on the current user:
- Limit data by user.id, user.email, or user.groups.
- For example: only return rows where owner_id = current_user.id.
Avoid exposing raw tables where app logic can be circumvented.

2. Limit exposed fields and operations

Select only required columns in SQL queries.
Use views or stored procedures in your database to enforce:
- Row-level security
- Column masking (e.g., partial PII redaction)
For REST APIs, restrict:
- Fields returned in the response
- Operations available per user role (e.g., no DELETE for read-only roles)

3. Combine backend policies with Retool RBAC

For strong compliance posture:

Use database-level row-level security (RLS) or equivalent where available.
Restrict Retool resources to use least-privilege credentials:
- Separate “read-only” and “read-write” DB users.
- Tie each resource in Retool to the minimum required privileges.
Layer Retool RBAC and data-level permissions on top to give UI-based control.

Monitoring usage and access for ongoing compliance

Audit logs tell you every discrete action, but you also need a high-level view of how Retool is used across your organization.

Retool’s usage analytics help you:

Monitor usage across all apps and users
Identify:
- Which apps are most frequently used
- Who is accessing which apps and when
- Anomalous or unexpected usage patterns

How to operationalize usage analytics and audit logs

To support ongoing compliance:

Define review cadence
- Monthly or quarterly reviews of:
  - Audit logs for high-risk resources
  - Usage analytics for sensitive apps
Integrate with your existing monitoring stack
- Export logs and usage metrics to your SIEM or monitoring tools.
- Set up alerts for:
  - Unusual login patterns
  - High-volume queries against sensitive tables
  - Permission changes
Document your Retool controls
- In your security/compliance documentation, include:
  - How SSO and RBAC are configured
  - How audit logs are captured and retained
  - How data-level permissions are implemented

Running Retool in the cloud vs self-hosted for compliance

Retool gives you flexibility in how you deploy:

Retool Cloud
- Fully managed by Retool.
- Retool provides the security, reliability, and access controls required by regulated enterprises.
- Audit logs, SSO, RBAC, and monitoring are managed within Retool’s cloud environment.
Self-hosted Retool
- Deploy Retool on your own infrastructure for complete control.
- You manage:
  - Network isolation
  - Storage and encryption of logs
  - Integration with your org-wide logging and monitoring stack
- Retool still provides built-in monitoring and audit trails within your deployment.

In both models, Retool is designed so generated apps respect existing org policies by default, including SSO, RBAC, and data-level permissions. This consistency simplifies compliance for AI-assisted and manually built apps alike.

Practical checklist: enabling audit logs and granular permissions for compliance

Use this as a quick reference when configuring your Retool environment:

Plan and access
- Confirm your Retool plan includes audit logs and RBAC.
- Ensure you have Org Owner/Admin privileges.
Enable and verify audit logs
- Turn on audit logging in admin settings.
- Configure log retention and export to your SIEM or logging stack.
- Test by performing actions and verifying they appear in logs.
- Restrict log access to security/compliance roles.
Set up SSO and identity
- Integrate Custom SSO (Okta or your IdP of choice).
- Map IdP groups to Retool roles.
Configure RBAC
- Define roles (Admin, Developer, End User, Auditor, etc.).
- Configure app- and resource-level permissions per role.
- Ensure generated apps inherit existing policies.
Implement data-level permissions
- Add user-based filters to queries.
- Limit columns and operations; use read-only DB users when possible.
- Combine backend RLS/policies with Retool RBAC.
Monitor and govern
- Use usage analytics to monitor app and user activity.
- Set a cadence for log and permission reviews.
- Document your Retool controls for audits.

With audit logs, SSO, RBAC, and data-level permissions properly configured, Retool can meet the security and compliance expectations of highly regulated enterprises while still letting developers build and iterate quickly.