These connections are created by the Super admin/Admin/Developers and authorized by the respective logged-in users. Unlike
admin connection, these connections can hold individual authorization for all logged-in users and can perform the integrations based on the authorization of the user who executes it. Administrators or developers can create a logged-in user connection using
built-in connectors (except for the
Zoho Backstage, which supports only
admin connection) or
custom connectors, allowing users to authorize the connection directly from the
live mode of the application. These connections enable the integration of external services within an application, providing authorization for individual users with authorized access to specific data and functionality.
Primary account
For creating
datasources and
schedulers using logged-in user connections, the primary account is necessary to channelize integrated services through a single account. For example, consider a scheduler workflow that automatically pushes data from a Creator application to Zoho CRM every day. In such cases, the scheduler runs independently without requiring user or admin actions. The scheduler utilizes the authorization of the primary account to perform its tasks.
In the case of
datasource, lets us consider a
Zoho CRM integration form where the data is pushed to the accounts module of the
Zoho CRM through a connection. In order to create a datasource, it is necessary to have a primary account. Here, the integration form will be created with the fields based on the fields in the specified
Zoho CRM module of the primary account. Each logged-in user can authorize this connection individually and add the data to the integration form, which will be added to the specified module of their
Zoho CRM.
When an admin authorizes a logged-in user connection for the first time, that account will be designated as a primary account. However, any administrator has the authority to change the primary account status and assign it to another administrator's account if needed. If you have not chosen to use the same authorizations for all environments during the creation of a connection, you can set different primary accounts for each
environment.
Click
here to learn how to mark an account as primary.
Note: Portal users and shared users can also authorize the logged-in user connections directly from the live mode of the application. Click
here to know more about accessing connection in live mode of the application.
When creating a user connection, you must choose how you want the OAuth credentials to be managed. Zoho provides two connection modes:
5.1. Zoho-managed credentials
Zoho-managed OAuth credentials use an OAuth application that is created and maintained by Zoho Creator. This default connection method eliminates the need for OAuth client configuration and lifecycle, including client IDs, client secrets, redirect URLs, and other OAuth components manually. The OAuth application is automatically managed and maintained, making it easier to authenticate common integrations with minimal setup while preserving user-level consent and access control. This method is ideal for the following scenarios:
No requirement for direct ownership or control of the OAuth application
Preference for simplified setup and reduced maintenance effort
Reliance on Zoho-managed credential handling to meet internal compliance requirements
For example, if a Zoho Creator app needs to access Zoho Sheets, the developer when creating a connection, selects Zoho-managed credentials. Zoho handles the OAuth app and configuration, and the user simply signs in and grants permission; no client IDs or secrets are required from the administrator.
5.2. Client credentials
Custom OAuth credentials allow you to use an OAuth application that you create and manage by registering it directly with the third-party service (such as Google or Microsoft). Instead of using Zoho-managed authorization, you provide your own Client ID, Client Secret, Callback URL, and other required OAuth configuration details. This method is commonly referred to as Bring Your Own Credential (BYOC) and is typically chosen when an organization requires greater control over how authentication is configured and managed. Users must authorize access to their accounts during connection setup, similar to Zoho-managed credentials.
This method is commonly used in the following scenarios:
Direct ownership and control of the OAuth application
Ability to define customized or restricted authorization scopes
Alignment with internal security, compliance, or regulatory policies
Control over token lifecycle, access permissions, and audit requirements
Although BYOC requires more setup effort compared to Zoho-managed credentials, it provides greater flexibility and governance, ensuring authentication behavior aligns with organizational standards, making it especially suitable for enterprise or highly controlled environments.