Client workspace
The client workspace gathers everything related to a client in one place: deals, tasks, files, documents, and external access. This lets you run and control the work on a client without manually piecing it together from different modules and private chats. For a manager, this is the main screen that answers the question "what is going on with this client?"
Open the workspace from the client record.
Why you need it
Without a single space, information about a client scatters: the deal sits in CRM, the tasks in the task module, the contract in documents, and the correspondence in chats. Getting the full picture becomes hard, and a new participant wastes time gathering context.
The workspace solves this: when you open a client, you immediately see their deals, tasks, files, documents, and external-access status, and you can also create new work right here - with a link to the client that is saved automatically.
Workspace tabs
The client space is split into tabs. The tabs have counters that show the volume of work on the client at a glance.
- Deals - this client's inquiries and deals. You can see what stage the work is in and where it has stalled. A new deal can be created from the client context.
- Tasks - tasks linked to the client, with the ability to create a task right here. This is handy when the client needs concrete execution: prepare a proposal, review a contract, make a call.
- Files - materials attached to the client.
- Documents - contracts, invoices, acts, and other documents linked to the client, with a counter of ready and pending items.
- External access (extranet) - the client's invitations and access to the client portal: for companies and contacts, this is where you manage invitations, links, and the access policy.
Additional tabs and “More”
Tabs depend on the record type and your permissions. A company may expose Contacts, Client projects, Commitments, Entitlements, Fulfillment, Billing, Legal entities, Documents, Links, Relations, Conversations, Discussions, Templates, and Settings; a contact or client project may expose only part of this set. An internal or client project may also have Activity. Less-used tabs can be under More. A missing tab means that the context, data, or available feature is not present, not that the record was deleted; Operations lists and invoices keep their own access and currency rules.
In the current wide layout, even key Operations tabs — Contracts, Commitments, Fulfillment, Entitlements, and Billing — can remain inside More. To compare them, open More and choose each tab in turn: the latest choice may appear in the main row, while the previous one returns to the menu. This is navigation behavior, not evidence that data or access is missing; do not assess a client only from the visible tabs.
A company or contact may also expose Contracts and Invoices. Contracts is a read/open list of existing contracts; it does not create a contract from this workspace tab. In Invoices, a switch separates invoices, pending accruals, and payments: an unapproved accrual may not have an amount yet, and payments may remain a counter when no action is available.
The main tab order is stable: Overview, Opportunities, Tasks, Contacts, followed by the other available tabs; Settings is not pinned ahead of working context. When a client has no opportunities, the money tile is not shown as a zero total. The card shows the owner and author when known; missing data is not replaced with technical statuses or identifiers.
Rows under Commitments and Entitlements link to their own cards. Open them to check the source, periods, remaining amount, and history. If the related object is not allowed or is still loading, the portal uses a neutral label instead of a technical ID; that does not prove the relationship is absent.
An entitlement balance is shown as the exact available / granted ratio in the purchased unit. For time, the portal may restate 480 minutes as 8 h and 390 as 6 h 30 min; do not recalculate it manually or treat a missing remaining value as zero.
When your session has actions.transferOwner, you can choose a new responsible person directly in the workspace header; the choice is saved immediately. The picker is hidden for an archived record, and without the transfer permission the current owner is read-only. In the activity feed, the author's name is resolved from the participant directory when an event snapshot is incomplete; if the name cannot be confirmed, the portal does not print a technical identifier.
The event text itself may arrive from the server already written in Russian and remain Russian in another-language interface; until the source is fixed, do not treat the feed as proof of full localization.
How to use the client space at work
- Create a task or a deal from the client workspace rather than separately: the link to the client is set automatically, and you will not have to attach the work by hand later.
- Use the tab counters as a quick indicator: many open tasks or deals with no movement is a reason to look closer.
- Keep client documents in the client's space, not in personal folders: then the contract and the invoice are found in seconds, not by digging through correspondence.
- Before connecting a client to external access, check that only what should be visible to the client will go outside.
Client project workspace
If the work on a client is divided into separate directions or projects, use the client project workspace. It also gathers tasks, deals, and materials, but within the boundaries of a specific client project. This helps keep different lines of work with the same client from piling into one heap.
Create a client project when the client has a standalone direction with its own tasks and outcome. If the work is one-off, a separate project is not needed - a deal or a task in the general client space is enough.
In the client-project list, click the project name to open its own card at /client-projects/<id>. The card has the project's own tabs, including Tasks; there is no separate Tasks button in the client row that would take you to the old general-space filter.
Project overview: description, checklist, and dates
Unlike the general client space, a client project has an overview of its own - the place that records how this project is set up:
- Project description - working context and important agreements in free form. This is what a new participant should read first: what we are doing, what was agreed, what counts as the outcome.
- Project checklist - the project's own steps. Items can be collected into groups, moved between them by dragging, turned into sub-items with "Make a sub-item of the previous one" and moved back with "Move up one level". The checklist shows progress.
- Project parameters - start, deadline, status, type, parent, tags, and owner; fields save separately, and an archived project is read-only.
Open the project from the client workspace in the same client context; the same rules apply to its status, type, parent, tags, and archiving.
The overview opens in view mode by default; editing is switched on separately, so the description and the plan are not changed by an accidental tap.
The project checklist is not linked to the project's tasks. It is an extended description - the project's own steps, not the team's list of work. Ticking an item does not close a task, and a completed task does not tick an item.
That leads to a simple split:
- the checklist - the plan and the agreements: how we run this project, what stages it consists of, what is already behind us;
- tasks - execution: each one has an assignee, a due date, and acceptance of the result.
If someone has to do a step and report on it, create a task. A checklist item is not assigned to anyone, does not remind about itself, and does not appear in anyone's list of work - the team simply will not see it as work.
Access
What is visible in the workspace depends on permissions. Some data may be hidden, and certain actions unavailable, if you lack the rights or are not a member of the linked work group. This is normal: request access from the space owner rather than working around the limit by forwarding data. The access model is described in more detail in the article about clients.
What a manager should check in the client space
The client workspace is a convenient control point for a specific client. When you review a client, check:
- deals: are there open deals with no next step or stuck on a stage;
- tasks: are there any overdue tasks for the client, and does each one have an assignee;
- documents: are the key documents in place (contract, invoice, act) and is the final version recorded;
- external access: who from the client's side is connected through external access, and is that still appropriate now;
- work focus: is the work kept in the client space or is it spreading across personal chats and folders.
Tab counters give a quick snapshot: if the number for deals or tasks looks unexpectedly large or zero, open the tab and look into it. Reviewing the client space regularly helps you catch stalled work and forgotten commitments before the client has to remind you.
States you may see
- a tab is loading or refreshing;
- a tab is empty - the client has no deals, tasks, files, or documents yet;
- a counter shows the volume of work and the pending documents;
- an action is unavailable because of permissions or lack of membership in the work group;
- some data is hidden by permissions.
After attaching or detaching a file, wait for row-level confirmation: the refreshed list should show the added file or remove the detached one. If the projection is still building or the read is delayed, the portal may show an operation notice while the list remains intermediate—reread the tab or retry the request. An empty list at that moment proves neither success nor failure.
An unavailable projection read does not block creating the file link: attach the file and verify the result separately by names and counts. A batch upload may partially succeed—the successful files and failed names are reported separately, so do not label the whole batch as failed. When the list is temporarily unavailable, a detach confirmation refers to the operation itself, not to an empty read.
Labels in the external access (extranet) tab follow the portal locale. Server-built activity text may still arrive in Russian regardless of the interface language; review that separately and do not promote a localized screenshot without fresh same-locale evidence.
Good practices
- Run all work on a client in the client's space, not in scattered modules.
- Create tasks and deals from the client context so the link is saved automatically.
- Watch the tab counters as an indicator of the client's status.
- Separate directions through client projects when the work requires it.
- In a client project, keep the agreements in the description and the checklist, and the execution in tasks.
- Before granting external access, check exactly what will become visible to the client.
Common mistakes
Running work on a client outside the client's space. The picture scatters, and no one sees the full history.
Creating a task or a deal separately and forgetting the link. Later you have to manually reconstruct which client it relates to.
Dumping all of a client's directions into one heap. Without client projects, different processes get in each other's way.
Keeping the work plan in the project checklist instead of tasks. The checklist is a description, not a set of assignments: its items have no assignee and no due date, they do not remind about themselves, and they are not linked to the project's tasks. The plan looks tidy while the work is assigned to no one.
Granting external access without looking. The client may see something not meant for them.
How to check the result
- the workspace opens from the client with the related deals, tasks, files, and documents;
- tasks and deals created from the context are genuinely linked to the client;
- the tab counters reflect the real volume of work;
- external access shows the client only what should be visible;
- data hidden by permissions is clearly understood as an access restriction.
Loading, access, and linked-object states
The account and contact cards keep the activity feed inside Overview; internal and client projects expose Activity as a separate tab. Tabs load lazily and non-core tabs can move into More until they have content or you select them. A denied workspace may show the owner, an allowed action, or a canonical card to open for an access request. A section read error is separate from the rest of the workspace and should be retried.
In Links, only safe http(s) addresses get an Open action; an unsafe address can remain copyable for review. In Relations, a known target can be opened while the relation itself can be deleted; a target hidden by permissions does not mean that the relation disappeared.
Related scenarios