Task Relations

In LadVen OS, relations help preserve work context: which task created new work, which client or project it belongs to, where documents are stored, which files confirm the result, and in which discussion the decision was made.

Use relations not as decoration for the card, but as navigation through work history. A participant should open a task and quickly understand where it came from, what it is connected with, where to find materials, and which nearby tasks may affect the result.

When a relation is needed

Relate a task to another object if, without the relation, participants would have to reconstruct context manually: search old correspondence, ask for a deal number, open several projects, or forward documents outside LadVen OS.

A relation is useful when:

• a large piece of work is split into several results;
• a new task appeared from a comment, file, document, CRM entity, or client request;
• the task belongs to a project, client, or client project;
• the result of one task affects another;
• the path from decision to execution must be preserved;
• the task has materials in documents, files, CRM, or comments;
• participant access to related context must be checked.

Do not relate a task to everything. Extra relations create noise: participants stop understanding which object is truly important for execution and which was added “just in case.”

Relations and responsibility

A relation adds context, but does not replace ownership of the result. Even if a task is linked to a client, project, document, and several nearby tasks, it must have one responsible person who understands what exactly must be brought to completion.

Use relations to answer four questions:

Question	Which relation helps	What still needs to be written in the task
Who or what is the work for?	Client, client project, CRM entity.	Which client result is needed and who accepts it on the team side.
In which workflow is this controlled?	Project, workgroup, parent task.	How the task affects the overall project result.
Where are source materials and the result?	Document, file, comment, checklist attachment.	What exactly to open, check, or attach at the end.
Which tasks depend on each other?	Parent, child, or related task.	What the dependency is: blocks, continues, clarifies, or records a decision.

If a relation does not help answer any of these questions, it is probably unnecessary. If it helps but is not clear without explanation, add one or two lines in the description or comment.

Types of relations

Tasks have several types of related context. They are similar because they help find the source of work, but they answer different questions.

Relation type	What it shows	When to use
Parent task	A larger task or initiative that produced the current task.	When the current task is part of an overall result.
Child task	A separate part of work inside the current task.	When part of the work has its own assignee, deadline, or definition of done.
Related task	A neighboring task without strict hierarchy.	When tasks affect each other, but neither is part of the other.
Project	Internal project, workgroup, or direction.	When the task should be found and planned inside project work.
Client	Company or client that the task relates to.	When the task matters for client history, sales, implementation, or support.
Client project	Specific project or workstream inside a client.	When one client has several parallel directions.
CRM	Deal, lead, contact, company, or another CRM entity.	When the task continues sales, support, or a client action.
Document	Document, spreadsheet, contract, specification, or work file in storage.	When the document is the source, material, or result of the task.
File	Attachment of a task, checklist item, or comment.	When material is needed for execution, review, or decision history.
Comment	Specific discussion, decision, question, or return for rework.	When new work appeared from discussion and the reason must not be lost.

Hierarchy, dependency, and context

Not all relations mean the same thing. Before adding a relation, define its management role.

What needs to be shown	Which relation to choose	How a manager reads it
The current task is part of a larger result	Parent or child task	The overall result has separate parts with their own owners.
The result of one task affects another	Related task	Tasks are not nested, but must be viewed together.
The task belongs to a team workflow	Project or workgroup	Work can be planned and filtered inside a direction.
The task belongs to client history	Client, client project, or CRM	The outcome must be visible in client context.
A material or evidence must be opened	Document, file, comment	The relation leads to the source, decision, or final result.

A child task is a separate result. A related task is a dependency, continuation, or new scope. A project and client are management context. A document and file are material or evidence. If these meanings are mixed, the card becomes an archive instead of a work assignment.

Parent and child tasks

A parent task describes the overall result. A child task describes a part of the work that can be performed and checked separately.

Create a child task if part of the work:

• has a separate assignee;
• requires a separate deadline;
• can be done in parallel;
• blocks the overall result;
• contains its own files, checklist, or discussion;
• must be visible in lists and reports separately from the parent task.

Do not turn every checklist item into a child task. A checklist is suitable for steps inside one result, while a child task is for a separate result with independent responsibility.

Good example:

Parent task:
Prepare the pilot launch for the client

Child tasks:
- Approve the pilot contract
- Prepare the technical connection scheme
- Collect the training participant list

Bad example:

Parent task:
Prepare the pilot launch

Child tasks:
- Open the template
- Write the text
- Check spelling

In the second case, use a checklist instead: separate tasks would add unnecessary navigation and blur the overall picture.

Related tasks

A related task is needed when tasks have a contextual dependency, but not a “part of whole” relationship. For example, one task records a client decision, another is a technical assessment, and a third prepares a document.

Use a related task if:

• the task continues a discussion from another task;
• the result of one task is needed for a decision in another;
• the work cannot be merged because tasks have different assignees or deadlines;
• a link to a previous attempt, canceled work, or alternative option must be preserved;
• part of the scope was moved out of the current task, but parent hierarchy does not fit.

Move only the necessary context into the related task: a short reason for the relation, a link to the source task, and important materials. Do not copy the whole correspondence manually. If an important decision was in a comment, it is better to link to it or record the outcome in the new task.

Creating a related task from context

Creating a task from context helps avoid losing the source of work. This is especially important when a task appears from another task view, a comment, CRM entity, document, file, or client project.

Working order:

1. Open the source object: task, comment, CRM entity, document, file, project, or client.
2. Start the action to create a task from this context if it is available.
3. Check which relation will be added automatically: parent, related, project, client, CRM, or document relation.
4. Formulate the new task title as an independent result.
5. In the description, briefly explain why the task appeared and where to view the source context.
6. Assign the assignee, deadline, and participants.
7. Attach only files or documents that are truly needed for execution.
8. Save the task.
9. Open the created task and check that the relation is displayed in the card.

If LadVen OS did not create the relation automatically, add it manually immediately after saving. Do not leave a task with only the phrase “as discussed”: after a few days participants will not reconstruct where exactly it was discussed.

Project, client, and client project

A project or client relation answers the question: “Which workflow does this task belong to?”

Relate a task to a project if the work is planned, discussed, and controlled inside a project team. A project helps filter task lists, group work, and see workload by direction.

Relate a task to a client if the result matters for client history: sale, implementation, support, contract, meeting, request, complaint, or regular service.

Use a client project when one client has several independent workstreams. For example, implementation, support, integration, and training can run in parallel but belong to the same company.

Good practice:

• project shows the internal workflow;
• client shows the external side of the context;
• client project clarifies the direction inside the client;
• CRM entity shows the specific sale, request, contact, or deal.

If a task belongs to both a client and a project, check that the selected relations do not contradict each other. For example, a client implementation task should not accidentally end up in another team’s project or under another client.

For a business owner and department manager, this is especially important in reports: the project relation is responsible for manageability inside the team, and the client relation is responsible for the history of relationships with the client. Do not use one instead of the other. A contract task can be in the “Implementation” project, related to client “Alpha,” and have a CRM deal; this is normal if each relation explains a separate context layer.

CRM relations

A CRM relation is needed when a task continues work with a sale, client, contact, company, lead, deal, or another CRM entity.

Add a CRM relation if the task:

• appeared from a call, email, meeting, or deal;
• affects the next sales step;
• is needed to prepare a proposal, contract, invoice, or implementation;
• records an action on a client request;
• must be visible from client history;
• requires participation from a manager, account owner, lawyer, implementation, or support.

In the task description, specify exactly what must be done in the CRM context. A link to the deal alone does not replace the task statement.

Example:

Context:
The task was created from the pilot launch deal. The client asked to confirm integration timing before the meeting.

What needs to be done:
Check technical limitations, agree on the launch date, and leave the final comment in the task.

Before closing the task, check whether the outcome must be returned to CRM: add a comment, update the stage, attach a document, or create the next task. If the decision remains only in the task, the manager may not see it in client history.

Documents and files

Documents and files provide materials: what to use as a basis, what to check, and where the result is stored.

A related document is suitable when the material lives as an independent object: contract, technical specification, spreadsheet, presentation, regulation, commercial proposal, or working document with edits.

A task file is suitable when the material is needed inside this task: brief, screenshot, export, final version, evidence of completion, or checklist item attachment.

Choose the place by meaning:

Situation	What to relate or attach
A contract edited separately must be used	Related document and a short explanation in the description.
A source brief must be handed to the assignee	Task file.
A step must be confirmed	Checklist item file.
An interim version must be discussed	File in a comment.
The final result must be saved	Task file or result document with a final comment.

Do not duplicate the same material everywhere. If a document is linked as a source, it is enough to write in a comment which part to check. If a file is the final result, state that in the definition of done or final comment.

Document practice:

• if a document is the source, specify the section, page, tab, or fragment to look at;
• if a document is working material, agree where edits are left and who accepts the final version;
• if a document is the result, record a task criterion: the link opens, the version is current, the right participants have access;
• if material is attached as a file, check its name and version relevance before assigning work;
• if a file appeared in a comment as the outcome, leave a final comment so participants do not have to search for the final version among interim attachments.

Comments as a relation source

New tasks often appear from discussion: someone found a separate problem, suggested an improvement, recorded a risk, or decided to move part of the work outside the current task.

When creating a task from a comment:

• save the link to the source task or comment if LadVen OS supports a direct link;
• restate the decision in the new task description briefly and clearly;
• specify what is outside the original task and why it was moved separately;
• add participants who need to see the continuation;
• leave a comment in the source task that the work was moved to a related task.

Example final comment in the source task:

Recording: we close the current task for manual review. We move automated reconciliation to a related task to estimate scope and deadline separately.

This way participants see not only the new task, but also why it appeared.

How not to lose context

A relation alone does not guarantee understanding. Participants need a short, verifiable picture: what is related, why it is related, and what to do next.

Minimum context set:

• the task title describes the result;
• the description explains why the task appeared;
• the source task, project, client, CRM, or document is specified;
• important files are attached or related in the correct place;
• comments record decisions that change the scope of work;
• participants have access to related objects;
• after creating the relation, navigation works in both directions if the UI supports it.

If the relation matters for execution, mention it in the task text. For example: “The work relates to the client implementation project; see the contract in the related document.” Do not make the assignee guess the relation meaning from the object name alone.

For acceptance, a review route is useful:

1. First open the source: parent task, CRM, document, or comment that created the work.
2. Then check the decision: what was agreed, who confirmed it, and which limitations were recorded.
3. Then compare the result: file, completed checklist, final comment, and related tasks for new scope.

If a manager cannot follow this route in a few minutes, the relation exists formally, but the context is poorly prepared. Add a short explanation to the description or final comment.

How not to blur work with relations

Too many relations make a task look like an archive rather than an assignment. A participant sees a client, project, CRM, documents, files, and neighboring tasks, but does not understand which one is primary.

To keep relations from blurring work:

• keep one result in the task title, not the full relation list;
• in the description, separate the context source from the expected action;
• do not attach a document only because it is on the same topic;
• do not add related tasks if there is no dependency or continuation;
• do not use a parent task as a folder for a whole direction;
• do not close the task without a final comment if the result must return to CRM, client project, or document;
• do not automatically assign all participants from related objects to the current task.

If execution requires opening more than three related objects, add a short route in the description: “first look at the contract, then the decision comment, then update the result file.” This saves assignee time and reduces the risk of using the wrong material.

Access rights and limitations

Related objects can have different permissions. A user may see the task but not the project, CRM entity, document, file, comment, or another related task.

Before assigning work, check access if:

• the task is related to a closed project, client, or CRM entity;
• a participant was added after the relation was created;
• the file or document is stored in a separate repository;
• the task contains commercial, personal, or internal data;
• the related task belongs to another team;
• a participant sees a muted record, hidden relation, or unavailable message.

Do not bypass permissions by forwarding files or screenshots outside LadVen OS. Then work history, access, and current versions diverge. If a participant needs access, configure it in the source object or ask the space owner for help.

If a relation is unavailable, the task should make the next step clear: request access, contact the object owner, replace the relation with an available document, or clarify context in a comment.

How to check relations

After creating or changing a task, open it in view mode and check the relations block and work context.

Check that:

• the parent task appears where expected;
• the child or related task is visible from the source task;
• project, client, and client project match the real work;
• the CRM entity opens and belongs to the correct client or deal;
• documents and files are available to participants;
• a comment or description explains why the relation was added;
• in the task list, the relation helps filter or group work;
• hidden or unavailable relations do not block execution without a clear next step.

If a relation was added by mistake, correct it immediately and leave a comment if participants may already have seen the wrong context.

Good practices

• Create child tasks for independent results, and use a checklist for steps inside one result.
• Use a related task for a dependency or continuation, not for visual grouping.
• When creating from context, check which relation was added automatically.
• In the new task description, restate the reason for the relation in human language.
• Do not copy the whole history manually: record the outcome and leave a link to the source.
• Check participant access to projects, clients, CRM, documents, and files.
• Store the final result where it is easiest to check: in task files, a related document, or a final comment.
• If a relation affects acceptance, add it to the definition of done.
• Do not add relations “just in case”: each relation must help perform, check, or find the task.
• For client tasks, relate work to a client or CRM only when the outcome must remain in client history.
• For project tasks, check that the relation helps the manager see work progress and does not merely replace a tag.
• For documents, record whether the document is a source, working version, or final result.
• For related tasks, write the dependency between them: “waits for result,” “continues decision,” “moved separately,” “blocks launch.”

Common mistakes

Creating one large task instead of several related tasks. If work has several independent results, different assignees, or deadlines, split it into child or related tasks.

Moving small steps into separate tasks. If a step has no separate result, keep it in the checklist.

Leaving a related task without explanation. Participants see a link but do not understand why it matters.

Relating a task to the wrong client or project. This breaks filters, reports, and client history.

Attaching documents without checking access. The assignee formally sees the task but cannot open the material.

Copying context instead of linking the source. Manual copies quickly become outdated and diverge from the original.

Closing the source task without recording moved work. Later it is unclear why part of the result was not done in the original task.

Using a CRM relation as a replacement for description. A deal or contact gives context but does not explain the expected result.

Deleting a relation without a comment. If people already worked by that relation, they need to understand why the context changed.

Adding all client materials to every task. The assignee loses the main source and may work from an outdated file.

Mixing project and client. A project is for internal management; a client is for external history. Choosing only one for convenience makes reports and search incomplete.

Treating a related task as the assignment itself. A link shows the source, but does not explain what exactly must be done and who owns the result.

Automatically adding participants from related tasks. People receive extra notifications, and responsibility becomes unclear.

Which screenshots are needed for this page

• Relations block in a task card: parent, child, and related task.
• Creating a task from a comment or another task with an automatically added relation.
• Example of a task related to a project and client at the same time.
• Example client task with a CRM entity and explanation in the description.
• Related document or file in a task where the material purpose is visible.
• Checking relations in task view mode after saving.
• Unavailable relation or file state when a participant has no access.

Related scenarios

• Create a task
• Assign participants
• Attach files to a task
• Add a checklist
• Task comments