Mailbox

Mail in LadVen OS is not a separate archive for correspondence. It turns important emails into managed work: a CRM opportunity, a task, a comment, a file, or the next customer step.

The mailbox helps the team see which emails require a reply, which are already linked to a client or opportunity, who owns the continuation, and where the final agreement is recorded.

Where to Find It

Main areas:

• Mailbox (/mailbox) - connected mailboxes, connection scenarios, and processing rules;
• Inbox (/mailbox/inbox) - email list, threads, folders, search, quick actions, and CRM context;
• Email card (/mailbox/:integrationId/messages/:messageId or opening from inbox) - body, attachments, senders, recipients, CRM actions, and reply;
• older /mailbox/messages/:messageId and /crm/mail* routes redirect to the current mailbox area.

Available actions depend on mailbox, CRM, task, and mailbox-specific permissions.

When to Use Mailbox

Use the mailbox when an email:

• starts a sale, request, support case, or client action;
• contains a file, agreement, question, or confirmation that must stay in work context;
• requires a task for an employee or department;
• must be linked to a client, contact, opportunity, or project;
• arrives in a shared mailbox where ownership must not be lost.

Do not leave important emails only in the inbox. If an email creates work, it needs an owner, deadline, context, and a place for the result.

Search on the mail server

Server search is a separate operation, not a filter over the portal list already loaded. Use a query from 2 to 160 characters; search the default folder scope or choose up to 8 folders. A search can request at most 200 previews. At most two jobs run at once, so another start may need to wait. States are queued, running, completed, failed, cancelled, and expired; the scan goes from newest messages backward, is bounded, and may return a truncated result. Results are remote previews, not downloaded messages: they cannot be opened in the portal until the provider syncs the message. Previews expire and must be searched again; cancel or dismiss unwanted jobs, and do not treat access/provider errors as an empty result. Jobs from another device may be invisible while still consuming the limit. Use synthetic queries for testing and never expose real addresses or subjects.

A remote preview may have no received date, so identical sender-and-subject rows cannot reliably identify one message. Sync or open the message through the provider before acting, and never display the technical uid as its label.

Connect a Mailbox

Choose the purpose before connecting:

• personal mailbox for the owner’s work correspondence;
• shared mailbox for a team, department, or business line;
• CRM mailbox for emails that should create or link opportunities.

Check the address, sender name, incoming and outgoing servers, secure connection, access rights, and notifications. For a shared mailbox, define who can read it and who owns processing.

For CRM scenarios, choose the pipeline, starting stage, owner, and routing rules so new emails do not stay in the inbox without an accountable next step.

Process Inbound Email

Read inbox items as work states, not only as messages.

Check:

1. Who sent the email and whether the sender is already a client or contact.
2. Whether an opportunity, client request, or task is already linked.
3. Whether a reply, file, clarification, or another person’s action is needed.
4. Whether the email should become a task.
5. Whether it should create or link a CRM opportunity.
6. Whether the team needs an internal note explaining the decision.

If the email is already linked to CRM, continue in the linked object. If it is not linked and it affects a customer commitment, create the link before the context is lost.

Quick Email Actions

Use quick actions only after checking the context:

• Reply - when the response must be sent from the right mailbox with a clear signature;
• Create opportunity - when the email starts a new client process;
• Link opportunity - when the email belongs to an existing deal or request;
• Open opportunity - to continue in CRM, not only in the mail thread;
• Archive - when the email is processed and needs no action;
• Delete - only when the email is not needed for work history.

If the email has attachments, decide which files must be saved to a task, CRM card, or documents. Do not leave an important file only inside the email thread.

Link Email to CRM

CRM linking is needed when an email relates to sales, support, payment, contract, repeated request, or client project.

A good link answers three questions:

• which client or contact wrote;
• which opportunity, request, or project the email belongs to;
• what the next human step is.

Do not create a new opportunity from every email automatically if the email continues an existing process. First check whether an active request or opportunity already exists for the same client.

Create a Task from Email

Create a task when the email requires concrete work: prepare a reply, check a file, approve terms, issue an invoice, update data, contact the client, or hand the question to another department.

The task should include the expected result, assignee, deadline or priority, email or CRM context, needed attachments, and a clear definition of done.

An email subject is not a task brief. The assignee should understand the work without rereading the entire thread.

Replies and Outbound Email

Before sending a reply, check the sending mailbox, recipients, copies, subject, attachments, and signature. For a shared mailbox, the client must understand which team answered and who owns the next step.

If the reply is linked to a CRM request, continue from the linked context. This keeps customer history together instead of splitting the decision between mail and CRM.

If an email fails to send, the portal shows this plainly and with a clear reason for the refusal, instead of swallowing the error: a delayed or queued send does not turn into a silent dead end. When you see such an error, check the recipient address, the mailbox connection, and the attachments, then send the email again rather than assuming it went out.

The Outbox keeps delivery facts separate. Queued and Scheduled mean that delivery is not complete; Sent is confirmed by its own sentAt, while scheduledSendAt is only the planned time. A failed row can expose a human-readable reason and, when allowed, Retry or Cancel. Open the attempt journal and technical reasonCode only for diagnosis: never present the code as the user explanation or treat a message as sent before the Sent state.

Before cancelling a queued or scheduled message, the portal opens a separate confirmation. Verify that the synthetic draft is the intended one, and stop before the final action when preparing documentation.

Do not send internal notes, draft files, private links, or team comments outside.

Shared Mailboxes

In a shared mailbox, access and responsibility are separate. Several people can see the email, but one person must own the next action.

Define who processes new emails, who watches overdue replies, which emails become CRM work, which emails become tasks, which notifications are needed, and when old emails can leave the local list.

Safety

If connection fails, check the address, app password, servers, ports, and secure connection. If emails do not appear, check access, folder, synchronization, and local retention settings.

If an email cannot be linked to CRM or a task, check access to the client, opportunity, or project; selected pipeline and stage; request owner; task creation rights; and whether the email was already linked to another object.

Do not copy passwords, tokens, internal technical URLs, or private client data into task titles or public comments. Describe the work result without exposing unnecessary details.

Good Practices

• Process inbox by meaning: reply, link to CRM, create task, leave note, close.
• For client emails, always check that the next step is visible in CRM.
• For tasks from email, write the result, not only the email subject.
• In shared mailboxes, assign a processing owner.
• Use internal notes for team context, but do not replace tasks and CRM decisions with them.

Thread queues and ownership

The inbox can be read as threads or individual messages. In thread mode, use the queues All, Mine, Unassigned, Waiting for us, Waiting for customer, Overdue, Snoozed, and Closed. A queue is a working view, not a separate copy of the mailbox; changing the queue only changes the list query.

For an open thread, assign it to yourself or another permitted teammate, mark whether the next response is expected from your team or the customer, and snooze it until a chosen preset when it should leave the active queue temporarily. The SLA badge distinguishes on-time, overdue, snoozed, and closed states. Close a resolved thread; reopen it when new work arrives. After a state action, reread the thread and retry only after checking the current state, because another operator may have changed ownership or status.

Automation and Order in Mail

When the flow of emails becomes large, process it not by hand but with rules and folders:

• Message card and work actions — triage, replies and forwarding, tasks from email, CRM links, attachment limits, and ACL/privacy.
• Inbound Email Rules — automatically create a CRM request, assign an owner, send an auto-reply, and sort emails by conditions (sender, domain, subject, attachments).
• Folder Management — create and maintain folders, move emails, and apply bulk actions.

Related Sections

• CRM
• Create a Task
• Task Comments
• Documents