Security

Explains the security model for Zoho CRM Functions.

3. Serverless Endpoint Security

5. Sandbox Development

This document explains the security model for Zoho CRM Functions, including access permissions, data access, endpoint exposure, and audit logging.

Permissions

Functions are governed by a single profile-level permission: Manage Extensibility, found under Developer Permissions in the CRM profile settings.

A user with the Manage Extensibility permission can perform all Function-related operations: create, edit, delete, deploy, manage arguments, configure REST API endpoints, and manage connections. A user without this permission cannot access the Functions area at all.

Note:

This is an all-or-nothing permission. There is no granular separation between viewing, editing, and deleting Functions. If a user has Manage Extensibility enabled, they have full access to all Functions in the org.

Who Should Have This Permission

Limit the Manage Extensibility permission to developers and administrators who actively build or maintain Functions. Granting it broadly increases the risk of accidental changes to live automation logic.

Standard CRM users who trigger Functions by clicking buttons or performing actions that invoke automation do not require this permission. Functions execute regardless of the triggering user’s profile permissions.

Recommendation for Admins:

If developers need to build or test Functions, consider restricting the Manage Extensibility permission in production and directing them to work within the Sandbox environment instead. Sandbox gives developers full access to write and test Functions against isolated data without any risk to production. Once development and testing are complete, the admin can review and deploy the changes to production. This keeps production Function logic under admin control at all times.

Data Access

Default Behavior

By default, Functions execute with admin-level access to CRM data. This means:

Functions can read and write all fields on all records, regardless of field-level security (FLS) settings.
Functions are not restricted by record-level sharing rules. They can access records that the triggering user cannot.
Functions can operate on any module, including restricted or private modules.

This behavior is by design. Functions are intended to run as system-level automation. A workflow-triggered Function that updates a restricted field will succeed even if the user whose action triggered the workflow has no access to that field.

When Connections Are Used

When a Function uses a Connection to make API calls, the access is scoped to the authenticated user of that connection, not the admin-level default. This means:

API calls made through a connection respect the scopes and permissions of the user who authorized that connection
If the connection was authorized by a user with limited access, the Function's API calls through that connection will have the same limitations
This applies to both Zoho service connections (e.g. zoho.crm via connection) and external service connections

Important:

It is important to distinguish between the two execution contexts. Direct CRM operations within a Function, such as zoho.crm.v8.getRecordById in Deluge or ZRC calls in Java, Node.js, and Python, use admin-level access. But when those same operations are routed through an explicit Connection, they respect the connection's authenticated user scope.

Best Practices for Data Access

Be aware that Functions can access sensitive fields (SSN, salary, private notes, etc.) even if they are hidden from most users via FLS.
Avoid logging or returning sensitive data unless it is required. Functions should process sensitive data, not expose it.
When building serverless endpoints that return CRM data to external consumers, be deliberate about which fields you include in the response. The endpoint itself has admin-level access, so it is your responsibility to filter the output appropriately.

Serverless Endpoint Security

Functions exposed as REST API endpoints support two authentication methods that can be independently enabled or disabled from the Glance View:

OAuth 2.0

When enabled, the endpoint URL requires a valid OAuth 2.0 access token. Callers must authenticate through the standard Zoho OAuth flow to obtain a token. This is the recommended method for production integrations.

API Key

When enabled, the endpoint URL includes a zapikey parameter, which is a static authentication key unique to your organization. This is simpler to set up but less secure, since the key does not expire and anyone with the key has access.

The API key can be regenerated from the Functions list page via Settings (gear icon) > Regenerate API Key.

Caution:

Regenerating the API key immediately invalidates the previous key for all Functions in the org. Any other Function endpoints using the previous key will stop accepting requests. Make sure you update all dependent integrations with the new key immediately after regeneration to avoid service disruptions.

Controlling Access

Enable only the authentication methods you need
If an endpoint only needs OAuth 2.0 access, disable the API Key toggle. Limiting authentication methods reduces the endpoint's attack surface.
Regenerate API keys periodically
If you use API Key authentication, regenerate the key on a regular schedule and after any suspected compromise.
Disable unused endpoints
If a Function's REST API is no longer in use, disable its authentication methods to prevent access to the endpoint.

Audit Logs

All Function-related actions are recorded in the CRM Audit Log, accessible from Setup > Security Control > Audit Log.

What Gets Logged

The audit log captures the full lifecycle of Function activity:

Action	What's Recorded
Create	Adding a new Function (e.g. "Added a Function named Detect ZAPIKEY as Argument")
Update	Editing a Function's code, arguments, or configuration (e.g. "Updated a Function named child for REST API Support")
Delete	Removing a Function
Execution	Successful or failed execution of a Function, including the trigger source (e.g. "Execution Success for a REST API Function named User Info")

Each log entry includes the timestamp, the user who performed the action, and a description of what changed.

Using the Audit Log

The audit log supports filtering to narrow down entries. Use it to:

Track who modified a Function and when. This information is useful for troubleshooting unexpected behavior after an update.
Verify that REST API endpoints are being called as expected. Execution entries confirm the endpoint is active.
Identify unauthorized or unexpected changes. The audit log records who modified a Function and when, making it easier to investigate unauthorized changes.
Export the audit log for compliance or review using the Export Audit Log option.

Note:

The audit log is org-wide and covers all CRM actions, not just Functions. Filter by action type or search by Function name to find relevant entries quickly.

Sandbox Development

Zoho CRM provides a Sandbox environment, which is an isolated copy of your CRM organization where you can safely develop and test Functions without affecting production data or live automation.

Why Use Sandbox for Functions

Functions run with admin-level access and can modify any record in any module. A bug in a Function, such as an incorrect field update, an infinite loop that exhausts API limits, or a malformed API call, can have real consequences in a production environment. Sandbox eliminates this risk by providing an isolated environment with its own data.

How It Works

Access Sandbox from Setup > Sandbox in the CRM sidebar.
Create or edit Functions in the Sandbox environment just as you would in production.
Test your Functions against sandbox data by triggering workflows, clicking buttons, invoking endpoints, and verifying the expected behavior.
Once satisfied, deploy the changes from Sandbox to Production using the CRM's built-in deployment mechanism.

What to Test in Sandbox

New Functions before their first production deployment.
Changes to existing Functions that modify record data or external API calls.
Functions that interact with multiple modules or have complex logic paths.
Serverless endpoints before enabling them for external consumers.
Connection configurations and authentication flows.