Creating a portal user in Zoho CRM gives external stakeholders — such as customers, partners, or vendors — controlled access to selective CRM data through a dedicated portal. This article walks you through the key steps to add, configure, and manage those users.
Why this matters
Zoho CRM Portals let you share specific records and modules with people outside your internal team without granting them full CRM access. [6] The portal owner (Super Admin) and any Admins they appoint can invite collaborators, assign roles, and define exactly which workspaces or data each person can see. [1] If you're rolling out a customer-facing vertical solution or a partner portal, getting user creation right from the start prevents permission headaches later.
> Note: Beam Help is independent expert support for Zoho — we are not official Zoho support.
---
Step-by-step
Step 1. Confirm your role.
Only the Super Admin (the portal creator) or an Admin they have appointed can add new users. The Super Admin holds full control over the portal, while Admins share most of that access except for subscription management. [1] Before proceeding, verify that your account has one of these roles.
Step 2. Navigate to the Portal Members area.
Open your portal and locate the Portal Members icon. Clicking it displays everyone currently in the portal. [2] If you manage multiple portals, go to the My Portals page first and select the correct portal before proceeding. [2]
Step 3. Invite the new user.
From the Portal Members panel, use the option to add a new member by entering their email address. Once submitted, the system sends an invitation to that address. You will receive a notification confirming the member was added successfully. [2]
Step 4. Assign workspaces and access levels.
When adding someone as a User (rather than an Admin), you must choose which workspaces they can access and specify their permission level for each one. [1] This is the step where you control exactly what CRM data the portal user can view or interact with — take care to apply the principle of least privilege here.
Step 5. The invitee accepts and logs in.
The new portal user will receive an email invitation. They click the acceptance link, then sign in with an existing Zoho account or create a new one. [4] Once signed in, they land on the portal view scoped to the permissions you configured.
Step 6. Verify the user appears in the member list.
Return to the Portal Members section and confirm the new user is listed. [2] If the invitation is still pending, you can navigate to the Invitations tab and use the Resend option to send the email again. [7]
---
Common pitfalls
- Switching an Admin back to a User: If you demote an existing Admin to a regular User, you will need to re-specify their workspace access and roles, since those settings are not carried over automatically. [2]
- Pending invitations not acted on: If the invitee doesn't receive or act on the email, head to the Invitations tab inside the portal's Custom Portals section and click Resend on their email address. [7] You can also click Revoke to cancel an outstanding invite entirely. [7]
- Portal user vs. regular CRM user: In Zoho CRM, a portal user is identified internally as a
"type": "Client Portal User"with a dedicated portal profile and role — distinct from a standard internal CRM user. [6] Don't confuse the two when configuring Client Scripts or automation that checks user type. - Deactivating vs. removing: If you only need to temporarily suspend access, use Deactivate rather than Remove. Deactivated users can be reactivated later, while removed users must be re-invited from scratch. [7]
---
What to check
- Membership confirmed: After sending the invite, open the Portal Members list and verify the new user appears there (or in the Invitations tab if they haven't accepted yet). [2]
- Correct workspace permissions: Review the workspaces and access levels assigned to the new user to ensure they match your intended data-sharing scope. [1]
- User type in CRM: If you use Client Scripts or automation, confirm the user is recognised as a
Client Portal Usertype rather than a regular internal user, so any portal-specific logic fires correctly. [6]