Extranet for Employees
This page is for the people who grant external access and own client service: portal administrators, department leads, and account managers. It explains how to connect a client to the extranet, limit their access to exactly what is needed, and support the joint work without putting internal data at risk.
How the portal looks through the client's eyes is described on the Extranet Client Portal page.
Where to Find It
External access management is collected in the Extranet Governance area (/extranet-governance). It contains:
- Client links — the list of user-to-contact-to-company connections with search and a status filter;
- Link wizard — step-by-step onboarding of a new external participant;
- Invitations — issuing invitations, controlling their lifetime, and revoking them;
- Permissions for the selected link — the company policy, the contact policy, and the resulting effective policy;
- Security — the password and session policy for external participants;
- Channel links — the Telegram and widget connections made by the client;
- Diagnostics — checking a specific link when access does not work as expected.
What External Access Consists Of
A client's extranet access rests on three things:
| Element | What it is | Why it is needed |
|---|---|---|
| Link | A connection between a user, a CRM contact, and one or more companies | Defines on whose behalf and in which client context the external participant works |
| Access policy | A set of permissions for the company and the contact | Defines what the participant can use: requests, chats, calls, pipelines, channel connections |
| Invitation | A one-time link for the first login | Lets the client create a password and enter the portal without manual credential handover |
Before granting access, make sure CRM has an up-to-date contact and company for the client. Linking to a draft or duplicate contact will later turn into confusion in requests and documents.
Link Wizard
The link wizard walks you through connecting a client in four steps:
- User. Find an existing portal user or create a new one: login, email, first and last name. A temporary password is set for a new user — the client changes it at the first login through the invitation.
- Contact and companies. Select the client's CRM contact and the companies they will work with. If there are several companies, assign a default company — the client will start their work from it.
- Review. Check the resulting user — contact — companies combination before confirming.
- Confirmation. Save the link. After that you can issue an invitation and configure permissions.
Example. The Vector agency connects a client — the Northern Light company. The manager creates a user for Emily Carter, selects her CRM contact, links the Northern Light company, and makes it the default company. Emily will see only her company's requests and documents.
Link statuses: active, disabled, revoked. Disabling pauses access without breaking the connection — convenient during a pause in the collaboration. Revoking is a final termination.
Invitations
An invitation is the only correct way for a client to log in for the first time. Do not send logins and passwords in correspondence.
The workflow:
- Select the link and the contact the invitation is issued for.
- Create the invitation — the system generates an activation link.
- Hand the link to the client through a trusted channel: to the contact's confirmed email or through an already established secure communication channel.
- The client opens the link, sets a password, and enters the portal.
Invitation statuses: pending, used, revoked, expired. An invitation has a lifetime — if the client did not activate it in time, revoke the old one and create a new one. Do not resend the same link repeatedly, and never use one client's link for another client.
Access Policies
An external participant's permissions are built from two levels:
- The company policy sets the overall perimeter: what is available to this company's participants at all.
- The contact policy refines the access of a specific person and can be narrower than the company policy.
The result is displayed as the effective policy — it is exactly what you need to check before granting access, not the individual settings.
Core permissions:
| Permission | What it opens | When to enable it |
|---|---|---|
| Request creation | The client can create requests in the available pipelines on their own | Almost always — this is the core extranet scenario |
| Request chat reading | The client sees the conversation on their requests | When the team is ready to run the discussion inside requests |
| Request chat sending | The client can write in the request chat | Together with reading, when you need a dialog and not only a status |
| General chat | A permanent communication channel with the company outside requests | For active clients with regular questions |
| Calls | Portal calls on requests and in the general channel | If the team actually takes calls in the portal |
| Telegram connection | The client can link Telegram for notifications and messaging | On the client's request, when the channel is agreed |
| Widget connection | The client can link a widget on their side | For integration scenarios agreed with the client |
| Allowed pipelines | Limits the directions where the client sees and creates requests | Always narrow the list down to the directions that are actually needed |
Start with the minimum set: request creation, request chat reading and sending, one working pipeline. Expand access as the need appears — it is easier than figuring out why the client saw something extra.
After every policy change, check the result in a test profile or together with the client: the list of requests, documents, and available actions must match expectations.
Security
The Security block configures the requirements for external logins:
- Password policy — minimum length, required lowercase and uppercase letters, digits, and special characters.
- Login policy — the number of failed attempts before lockout and the lockout duration.
- Sessions — the access lifetime, the session refresh lifetime, and the invitation lifetime.
Tighten the requirements if contracts, financial documents, or personal data go through the extranet. Remember that the policy applies to all external participants: sessions that are too short will turn into constant re-logins and client complaints.
Documents for the Client
The client sees in the portal only the documents published for their company or contact. Before publishing, check:
- the document belongs to the right company and contact;
- the file contains no internal comments, draft notes, or other clients' data;
- the document status is clear to the client: what is expected from them — review, approve, or sign;
- if a signature is required, the signing action is available to the client.
An employee starts the signature request after publishing the document. Do not publish a document just in case: every extra paper in the client portal is a question from the client and lost team time.
Working with Requests on the Team Side
- Reply in the chat of the specific request, not in the general channel — this keeps the history tied to the request.
- Do not ask the client to duplicate data that is already in the request form. If something is missing, ask for the specific field or file.
- Keep the request status up to date: for the client, the status is the main source of understanding what is happening.
- If a request is waiting for client actions, make sure the status and the last message make it clear which ones.
Channel Links
If the policy allows it, the client can link Telegram or a widget and receive updates outside the portal. The Channel links section shows which connections are active. Revoke the links when the responsible person changes on the client's side and when the collaboration ends.
Diagnostics
If the client sees something extra or cannot see what they need, do not work around the problem by manually forwarding files and links. Open Diagnostics, check the specific link, and walk the chain: user — contact — companies — effective policy — object visibility. Almost every access problem is explained by one of these links in the chain.
Ending the Collaboration
- Disable or revoke the client's link.
- Revoke active invitations.
- Revoke the Telegram and widget links.
- Check that unfinished requests are closed or handed over.
Checklist Before Granting Access
- The client's contact and company in CRM are up to date and not duplicated.
- The link points to the correct user, contact, and companies.
- The default company is selected correctly.
- The effective policy is checked: pipelines, requests, chats, calls, documents.
- The invitation is created for the correct contact and delivered through a trusted channel.
- After the client's first login, the access is checked one more time.
Common Mistakes
- Access granted by eye, without checking the effective policy. An individual company or contact setting does not show the result — check the effective policy specifically.
- One account for several people on the client's side. Create a separate user for each person: otherwise it is impossible to tell who wrote and signed what.
- Forwarding old invitations. An activation link is access. Revoke expired and unneeded invitations.
- Broad access to avoid configuring twice. Extra pipelines and chats will sooner or later show the client someone else's context.
- Forgotten links after the project ends. Make it a rule to review active links when closing a collaboration.