Clients, companies, and contacts

The client base is the foundation of CRM. When records are kept carefully, all the other work (opportunities, tasks, documents, correspondence) gathers around the right client, and the manager sees a complete picture. When the base is full of duplicates and unverified data, the history scatters across different cards, and decisions are made blind.

This page explains how to create and maintain clients, companies, and contacts so that the base stays manageable.

Where to Find It

CRM stores the participants of a relationship across several linked areas:

• Clients (/clients) - a single entry point to client records and their workspaces. This is a convenient place to start: find a client and open their workspace.
• Companies (/clients/companies) - counterparty organizations: the company card, legal and registration details, related contacts, and opportunities.
• Contacts (/clients/contacts) - specific people: full name, role, contact methods, and the company they belong to.
• Legal entities (/clients/legal-entities) - legal entities with the details used for documents and settlements.

Open the contact registry at /clients/contacts; a specific contact card can be opened at /clients/contacts/:contactId. The card content and available actions depend on your permissions.

The set of available areas and actions depends on your permissions. If a CRM item is not visible in the navigation, your role has no access to the module - this is not an error, it is an access setting.

Company registry

/clients/companies is the dedicated registry for organizations. Search by name, narrow the list by owner, and enable Show archived when you need archived records. Each row shows the company name and type, industry, phone or website, owner, state, and last-updated date. Selecting a row opens the client workspace at /clients/account/:accountId, with its tabs and related materials. For the company's own details, select Company card in that workspace; it opens /clients/companies/:accountId. In its configured file fields (logo, stamp, or signature), a user with edit permission can upload, replace, or remove a file; a readable file name is shown when it is available, with an image preview. If the field instead says that the file is unavailable, do not copy the technical value or substitute another file—ask the portal owner to check its access or state.

On a phone, the company card keeps the company name as the link and shows up to four available, non-empty facts; empty fields are omitted. This is responsive presentation, not evidence that data was deleted or unavailable: the desktop table may show an explicit missing-value marker.

Results load in pages. The counter above the list is exact only when the portal explicitly says that the portal confirmed the total; otherwise it is a lower bound for the records loaded so far. An empty list with active filters means you should clear the filters before creating a new company.

If the summary already shows clients while the table remains empty or intermediate, do not create a new record. Choose Retry or refresh the list, check filters and permissions, and report the mismatch to an administrator if it persists—the list is not ready for a duplicate decision.

The registry uses shared states: loading shows a skeleton, a read error offers Retry, and an unfiltered empty result offers to create the first company. When filters are active and nothing matches, use Reset filters before deciding whether a new record is needed. The results header reports loaded rows and the confirmed total; the row action archives or restores a record when you have write permission. An active company has no separate state badge—markers are reserved for archived or inactive records.

Create opens a company form with a required name, type (company, partner, or vendor), industry, website, phone, owner, legal entity, and tags. Website and phone are validated before saving. Archiving and restoring require write permission; without it, the portal explains the restriction instead of silently attempting the action.

For row actions, the portal checks separate server verdicts: archiveAccount, unarchiveAccount, updateAccount, and transferOwner. A denied action shows its reason beside the control; a missing verdict means “unknown”, not an automatic denial, so the server remains the final authority. General edit permission alone does not guarantee that a company can be archived or have its owner transferred.

A Client Record Answers Simple Questions

A good client record gives the answer without anyone having to ask:

• who the client is: an individual or a company;
• who the contact person is and how to reach them;
• which company and legal entity are involved in the relationship;
• who on the team owns the client;
• what access restrictions apply to the data.

Do not turn the card into a dumping ground for notes. Keep everything that relates to specific work in an opportunity, a task, or a comment, and keep stable facts about the client in the client record.

How to Create a Client Without Duplicates

A duplicate client is one of the most expensive mistakes in CRM: correspondence, documents, opportunities, and tasks split across different cards, and neither the manager nor the leadership sees the full history.

LadVen OS does not automatically block duplicates at creation time, so checking is a working practice, not a button:

1. Before creating a new record, use search.
2. Check the client by several attributes: name or full name, phone, email, related company.
3. If a similar record already exists, work in it instead of creating a second one.
4. If the client's data has changed, update the existing card rather than creating a new one.
5. If a duplicate does appear, do not combine cards or move history solely because the names match. A name from a messenger does not prove identity: agree an owner, work in the confirmed card, and keep unverified records separate.

Enter contact data only after verification. If information is not confirmed, note that in a comment or next step instead of turning an assumption into a fact in the client card.

caution

An empty list is not always proof that the client does not exist. If a message above the list says the chosen filters do not work in this view, no records are shown at all - and you must not create a new record from that screen. Clear those filters first, then decide about the duplicate. See the filters section below.

Search and filters in the client list

The client list is searched with the search box and narrowed with the "Filters" button above the list. The button carries a counter of active filters, so it is immediately clear that the list is not shown in full.

The available filters are:

• record type - a company or an individual client;
• owner - which employee handles the client;
• attention state - healthy, watch, at risk, unknown;
• reminders - overdue, today, upcoming, no reminder;
• no contact, days - clients you have not spoken to for longer than the stated period;
• last touch, next touch, reminder due, updated - "from" and "to" ranges.

The set of available filters depends on the view and on your permissions, so some of them may not be shown.

The list is not shown because the filters are not served

A separate state worth recognising: instead of the list, the message "These filters do not work in this view" appears with a "Clear these filters" button.

This is neither an empty result nor a failure. Some filters are not served in every view of the list, and rather than show records with part of the conditions silently ignored, the system does not show the list at all. Otherwise the screen would carry the full set of clients looking as if it were filtered - and it is easy to make a wrong decision from that.

What to do:

1. Do not read it as "there are no such clients" and do not create a new record from that screen.
2. Click "Clear these filters" or switch to a view where the filters you need are served.
3. Make sure the list is showing records, and only then draw conclusions or run bulk actions.

Bulk actions on the client list

In the list you can tick several clients (or select all the loaded ones) and apply one action: "Archive selected" or "Restore selected". The selection is cleared with a separate button. A limited number of records is processed at a time - if you selected more, the portal will say so.

Before writing, the portal runs a safe preview showing how many records are allowed, already in the target state, or unavailable. A clean selection is applied directly; a confirmation dialog appears only when part of the selection will be refused or skipped. After success, reread the list; to reverse the result, select archived records separately and use Restore selected — there is no Undo control.

caution

Archiving a client does not archive the work attached to them. In the confirmation dialog the portal states directly how many work groups and client projects of those clients will stay active. They must be closed separately.

Otherwise you get a dangerous mismatch: the client counts as closed while the work group on them is alive - tasks run, people work, and nobody sees the contradiction.

How to archive in bulk safely:

1. Check that the list really shows what you think it does: no message about unserved filters, and the filter counter matches your intent.
2. Tick the records and read the preview; if the result is partial, read the breakdown in the confirmation dialog.
3. Separately handle the work groups and client projects the portal warned you about.
4. If some records did not go through, open them individually and work out the cause instead of repeating the bulk action blindly.

Companies, Contacts, and Legal Entities

Keep the roles of records distinct:

• A company describes the organization as a whole: who we work with, what contacts and opportunities it has.
• A contact describes a person: who exactly we talk to and what role they play in making decisions.
• A legal entity is needed for documents and settlements: the details that contracts, invoices, and acts are issued against.

One company can have several contacts and be linked to a legal entity. Before sending a client a document, check that the correct legal entity is selected and that the details belong to that specific company.

The legal-entity registry is available at /clients/legal-entities. It shows the name, tax ID, registration fields, linked company, and last update; search by name or tax ID, include archived records when needed, and load more results. Archive stale records instead of deleting them, and use /crm/legal-entities only as the legacy redirect. Editing and archive/restore actions require the matching permission; loading, empty, and failed states should be read as states to retry, not as proof that records disappeared. Archive from a row or in bulk. A successful single-row action can offer Undo; a bulk result only reports its outcome. Reread the list and explicitly restore archived records, and inspect rows that fail because of permissions or state instead of blindly repeating the batch. A sole proprietor may have no KPP/registration code; a dash is normal. Fill registry details from incorporation documents, not invoices or email.

The Create button and Edit action open a modal with a required name and linked-company search. Search may be loading, empty, or failed: check the query and retry instead of entering a technical ID. Creating, editing, and archiving require write permission; when saving is refused or fails, the portal should show the reason—correct the field or request access rather than blindly repeating the mutation.

Selecting a row opens this same edit dialog; there is no supported /crm/legal-entities/:id detail page. The linked company name is a separate navigation link. Treat the registry count as exact only when the portal explicitly confirms the total; otherwise it is a lower bound or unknown.

The /clients/contacts registry supports search, owner, company, legal-entity, and archived-record filters, paged loading with a confirmed total, and links to contact cards. Rows show the name, role, company, work email, and owner; a decision-maker marker helps identify whom to speak with. Row and batch archive/restore require write permission; when the server refuses, the portal shows its reason, and a successful action offers Undo. The row checks the archive action itself: if a contact has active conversations or is the company’s primary contact, the button is disabled in advance with the reason. General permission to edit a contact does not guarantee that it can be archived; if the row has no verdict, the server remains the final decision-maker.

Creating a contact opens a modal: full name is required, and email and phone are format-checked. Choose the linked company, legal entity, and owner through search rather than inserting technical IDs. If saving fails, correct the data; if permission is refused, request access and do not blindly repeat the mutation.

On a contact card, edit the name through separate first-name and last-name fields; the portal composes the full name. Do not create a second record merely because an older record supplied the name in a different structure. If empty Company, Legal entity, Source, or Tags fields are not editable for you, they are collected under “Not filled in” instead of silently disappearing; phone, email, owner, and status remain separate fields. “Hidden by permission” is different: it means access is restricted, not that the data is empty.

When the contact has a selected company, its value on the card opens that company's card; while editing, use Open company card. This checks details and linked files without entering a technical ID by hand. If the link shows a technical code instead of a name, it is not the company name or proof that the company was deleted: do not copy or publish it; refresh the card or ask the portal owner to check the relation and access. No link means only that no company is selected.

On a contact card, voice eligibility is separate for each purpose: sales, retention, service, and collections. Only a Can call verdict permits a call; an unknown or expired verdict, an opt-out, or a block denies it. The record shows its basis, source, and effective-until date. With write permission, use Record to overwrite the basis, source, and expiry; there is no delete action. This is a right-to-call record, not a technical block: the number may still be dialled, so provider availability does not override the verdict. Opportunity List and Kanban show only a compact summary of the current contact check: a missing or unreadable answer is not permission and can differ by row because of contact access. Do not call on a warning—open the contact card or the call-entry form. If saving fails or permission is denied, correct the record or request access instead of blindly repeating the mutation.

You can export the contact list to Excel when you need a slice for a report or a mailing. Before exporting, make sure it does not include data that must not be shared externally.

Company reminders

The company card has a reminders block: a "New reminder" button and a list of what has already been set. It lets you pin an obligation at the level of the company instead of keeping it in your head or in a personal calendar.

A reminder has a title, a due date, an assignee, and a comment. In the list each reminder shows its state: active, snoozed, overdue, done, or cancelled. Row actions are available: edit, mark as done, cancel.

Not everyone can create reminders - it depends on permissions. If creating is unavailable to you, the block does not show a dead button; it explains who can set a reminder.

When you need this. A company reminder suits obligations that concern the relationship as a whole rather than a specific deal: call back after a pause, renew the contract, check a payment, return to the client after the season. If the action concerns a specific deal, set the reminder there - then it is visible alongside that deal's history.

A reminder is not a task. A reminder is a personal signal to come back to something. A task is work with an assignee, a due date, and acceptance of the result. If someone has to do something and report on it, create a task rather than a reminder: nobody but the addressee tracks a reminder.

The Client Workspace

The client record opens a workspace - a single place that gathers the opportunities, tasks, files, documents, and external access for that client. This lets you run and control all the work for the client without assembling it manually from different modules.

Use the workspace as the assembly point: create a task or opportunity directly from the client context so the link is preserved automatically rather than reconstructed later from memory.

Access and Personal Data

CRM stores sensitive data, so access to it is governed by permissions, and not everything is visible to everyone.

• Module visibility. If a role has no CRM permissions, the area is hidden from the navigation entirely.
• Restricted access. Some users see only certain pipelines, clients, or fields. When access is restricted, some actions become available only after a specific object is selected.
• Hidden fields. Individual fields, especially personal data and legal-entity details (tax IDs and registration numbers), may be shown as "Hidden by access policy." This means you can see the record, but you have no access to that data.
• Work group membership. Sometimes a record is visible but the action is unavailable because you are not a member of the related work group. In that case, ask the owner to add you as a participant instead of working around the restriction.
• External participants. A client can be connected to external access (a client portal) through a separate invitation mechanism. This is a managed scenario, not the ordinary granting of permissions to an employee.

Do not try to bypass an access restriction by forwarding data outside CRM. If access is genuinely needed, an administrator or the space owner should configure it.

Cleaning Up Duplicates

If duplicates have already appeared, separate them as early as possible - the longer work runs across two cards, the harder it becomes to reassemble the history later.

The order for cleaning up:

1. Find all records for the same client by searching on name, phone, email, and related company.
2. Choose the primary record - usually the one with more history and more up-to-date data.
3. Do not move links, history, or details between cards solely because the names match. First confirm a distinguishing fact through the approved procedure; if there is none, keep the records separate and escalate the decision to the owner.
4. Agree as a team on which record is the primary one, so that new opportunities and correspondence go into it.
5. Mark a record as no longer current only after a confirmed decision; do not close a card as “extra” from a name alone.

The current CRM has no safe automatic merge: do not bypass that boundary with direct calls or bulk manual moves. It is better not to let duplicates happen at all: the discipline of searching before creating is cheaper than untangling a diverging history. If duplicates appear regularly, that is a signal to fix the client-intake process rather than to fight the consequences by hand every time.

States You May See

• a record is loading or a list is refreshing after a search;
• nothing was found for the query - check the wording and filter before creating a new record;
• the list is not shown, with a message that the chosen filters do not work in this view - this is not "there are no clients": clear those filters or switch the view and look again;
• the bulk-action confirmation warns that work groups and client projects will stay active - close them separately;
• a field is shown as "Hidden by access policy" - you have no access to that data;
• an action is unavailable: no permissions, no object selected under restricted access, or you are not a member of the work group;
• the data was changed by another user - refresh the card before retrying the action.

Good Practices

• Always search for an existing record before creating a client.
• Before drawing a conclusion from the list, make sure it is shown at all and not replaced by a message about unserved filters.
• Enter only verified contact data; keep assumptions in a comment or next step.
• Before a bulk archive, close the work groups and client projects of those clients separately.
• Keep one client in one record, and keep the work for that client in their workspace.
• Record obligations towards a company as a reminder in its card, not in a personal calendar.
• Before sending a document, check the company, legal entity, and details.
• Do not export contacts with data that must not be shared externally.
• If a field is hidden by access policy, request access instead of looking for workarounds.

Common Mistakes

Creating a second client instead of searching for the first. The work history splits, and no one sees the full picture.

Taking the unserved-filters message for an empty result. The list is not shown at all at that moment, rather than being empty. Deciding "there is no such client, I will create a new one" from that screen produces exactly a duplicate.

Archiving clients in bulk without closing their work groups. The client is filed as archived while work on them keeps running - nobody notices the contradiction until it surfaces with the client.

Recording unverified data as fact. The team starts acting on a wrong phone number, email, or set of details.

Keeping client decisions in private chats. A new participant cannot see the context, and the manager cannot verify the agreements.

Ignoring a permissions warning. Bypassing a restriction by forwarding data creates a leak risk and makes control impossible.

Sending a document with the wrong details. A mixed-up legal entity leads to legal and settlement errors.

How to Verify the Result

• the client is found by search and is not duplicated;
• the client list is genuinely shown and not replaced by a message about unserved filters;
• after a bulk archive, those clients' work groups and client projects are closed too;
• it is clear who the contact is, which company and legal entity are linked, and who owns the client;
• the record opens a workspace with the related opportunities, tasks, and documents;
• fields hidden by access policy read as an access restriction, not as empty data;
• sensitive data does not end up in exports or shared externally without need.

Related Scenarios

• CRM: overview
• Tasks
• Documents
• Forms
• Extranet