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. Copy it right away: the link is shown only at this moment and never reappears on the invitation card. Close the page without copying, and you have to revoke the invitation and issue a new one.
- 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. If the panel shows a technical pipeline ID instead of a name, treat it as diagnostic: verify the mapping in the policy editor or pipeline list, and never publish the ID as a user-facing name.
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 creates a link and completes it through the Telegram bot; notifications are ready only when delivery is working, and a legacy link can require migration even while linked | On the client's request, when the channel is agreed |
| Widget connection | The client creates a link with an empty request body and checks the resulting state in the portal | 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.
When calls are enabled, the client can start or join a call in a request or general-chat context. During a call, mute, camera, screen sharing, and fullscreen are available; Leave ends the client's participation, while Finish ends the call for an authorised participant. If permission, device, or media access is denied, the button may be hidden or show an error—check permissions and channel state instead of retrying blindly.
Security
On the extranet governance page, the Security block is currently a policy readout, not an edit form. It is marked as externally managed: it shows the selected profile (smb, business, enterprise, or custom), password requirements, and access, session-refresh, and invitation lifetimes. When present, the page also shows current overrides and the resolved policy as a technical view; Refresh reloads the data. Change these rules in the policy source assigned to your deployment, and do not promise that a user can save them in this block.
The displayed parameters include:
- 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 create a Telegram or widget link, but creation does not mean delivery is ready. If the portal says that the Telegram integration is not connected, a manager must enable it before the client retries the link. For Telegram, the portal first shows pending and a one-time code with a limited TTL. Never publish or screenshot that code: the client sends it to the Telegram bot through the intended flow, then selects I've connected — refresh. Notifications and messaging are ready only when delivery is working; even linked can require migration for a legacy link; revoked means the connection has ended. A widget does not use a Telegram code: send its empty-body request and verify the binding state in the portal. Revoke pending and linked bindings when the responsible person changes on the client side or when the collaboration ends.
Linked does not always mean that delivery is working: a legacy link can remain linked while migration is required. In that case, a manager starts migration in governance or asks the client to reconnect Telegram. The client sends the full /bind <code> command to the bot, not only the code, and then refreshes the links. The code is one-time and has a TTL; after a reload or another tab takes over, the local code may be gone, so issue a new one. An expired code, a missing command/wrong bot, and Telegram already bound to another account need different next steps: a new code helps only in the first two cases; an administrator must release the conflict.
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.
Related Pages