Assign Participants

In LadVen OS, participants define who formulates the result, who is responsible for delivery, who helps, and who only follows the progress. Add people by role, not "just in case": extra participants blur responsibility and create unnecessary notifications. When a task is assigned to a department, the card shows an assignment decision band: the selected person can accept or decline with a reason, and a decline leads to reassignment, manual selection, or an exhausted queue. These pending/accepted/declined states describe the incoming handoff and do not replace task roles.

The assignment band is a separate decision on an incoming handoff: the Accepted label does not change the task's system status by itself, so the task may still be New. Attempt N counts a handoff in the queue; its ceiling and any relation to the number of people are not proven, so do not read it as “N of M” or promise a limit.

Main Rule

A task must have one main assignee. This person does not have to do every step personally, but is responsible for bringing the task to a verifiable result.

If several people have independent results, create several related tasks. If one person owns the overall result and others complete separate parts, keep one assignee and add the others as co-executors.

Roles

In the task card, the assignee and co-executors are shown as one team — the "Executors" block. The lead executor (responsible for the result) is marked with a star ★ and the "Assignee" label, and the rest appear as co-executors. This is easy to read, but the management meaning does not change: the result still has a single owner. The requester and observers are shown separately from the executors block.

Requester (Reporter role)

The task requester formulates the result, explains the context, and accepts the work. In the interface this role may be labeled Reporter; in the workflow, it is the person who needs the task outcome or owns the process in front of a client, manager, or team.

The requester must be available for clarification. If the requester will not be able to verify the result, specify in advance who will accept the work instead: in the task description, in a comment, or through observers.

Usually the requester is the person who creates the task. During creation, a department manager may set a subordinate as the requester when the task is being created on behalf of the employee who owns that workstream. In that case, the task is linked to the selected requester's workgroup or project.

This assignment does not make the manager a hidden owner of the result: the requester still owns the expectation and acceptance, while the assignee owns execution. The requester can be changed this way only while creating the task and only when the user has rights to the selected employee and their work context.

Assignee

The assignee moves the task toward the result: updates the status, asks questions, coordinates co-executors, and reports blockers.

Assign the person who can actually bring the task to completion. Do not use the assignee role as a way to "call everyone": when several people are effectively responsible, nobody understands who makes the final decision on execution.

In the "Executors" block, the assignee is marked with a star ★ as the lead executor — so the executors team can immediately see the owner of the result.

Co-executors

Co-executors are needed when other people perform part of the work: prepare a file, provide a technical estimate, approve text, collect data, or check a separate block.

Add a co-executor only if they have a clear part of the work. It is better to record that part in the description, checklist, or comment so the co-executor understands what they own and the main assignee can see progress.

Observers

Observers see task progress and receive context, but are not responsible for execution. This is useful for a manager, adjacent team, client manager, or anyone who needs to stay aware of the decision.

Do not add observers "just in case". If a person only needs to know the final outcome, mention them in a comment after completion or send a link to the task once the result exists.

Role Management Standard

For a manager and business owner, task participants are not just a list of people. They are the responsibility map. It should be clear who formulated the expectation, who delivers the result, who helps, and who only follows the work.

Before starting a task, check roles as a management agreement:

Question	Where the answer should be	What to do if there is no answer
Who accepts the result?	Requester (Reporter role) or an explicitly named reviewer in the description/comment.	Assign a requester who can accept the work or record the reviewer.
Who owns the outcome?	One assignee.	Choose one result owner or split the work into several tasks.
Who does separate parts?	Co-executors with concrete steps in the description, checklist, or comment.	Clarify each co-executor's contribution or remove extra participants.
Who must see risks during execution?	Observers who really need the process, not only the final outcome.	Keep the person out of observers and mention them when a decision appears.
Who owns client communication?	Requester (Reporter role), observer, or co-executor for client clarifications.	Add the client manager in the correct role without mixing their responsibility with another department's work.

If a task matters for a client, money, project deadline, or handoff between departments, check roles before saving. A participant mistake almost always appears later: questions go to the wrong person, acceptance is delayed, and the manager sees many participants but no owner of the result.

Do not add a business owner as an observer only "for visibility." If they need overall control, use saved slices, reports, and final comments. Add the business owner to a task when they personally accept the result, remove a risk, or need to make a management decision.

How to Distribute Roles in Work Situations

Roles are not for formally filling out a card. They are for managed work: who makes the decision, who delivers the result, who does a part, and who needs to see progress.

Situation	How to assign participants	Why
A manager assigns a task to an employee in the department	Manager is the requester, employee is the assignee. Do not add others unless they participate.	The result has an owner and clear acceptance.
A manager handles a client request while a lawyer prepares the contract	The manager or client owner is the requester, the lawyer is the assignee, and the manager may be an observer or co-executor for client clarifications.	Responsibility for the document is not mixed with responsibility for client relationship.
Several departments prepare independent parts of a launch	Create child or related tasks with separate assignees, and keep one launch owner in the general task.	Every result has its own assignee, and the launch does not turn into a list of assignments without an owner.
Only approval from a manager is needed	Do not make the manager the assignee. Keep them as requester, observer, or mention them in a comment at acceptance.	The assignee remains the person who drives execution, not the person who must say "yes".
A person must provide data for the executor	Add them as a co-executor and record their part in the description or checklist.	The participant understands what is expected and does not become a hidden co-owner of the whole result.
Only the final result needs to be communicated	Do not add an observer in advance. Share the outcome in a comment or send a link after completion.	Fewer notifications and more attention to tasks where the person really needs to follow progress.
A manager assigns a task to a subordinate and changes the executors	A department manager can reassign the executors on a subordinate's task, even if they cannot change anything else in the task.	The manager controls how work is distributed independently of the rights to edit the task body.

If a role causes disagreement, ask a simple question: "Who will be responsible if the task is not ready on time?" That person should be the assignee or the owner of a separate related task.

When a task is addressed to a department.

A task can be addressed to a department instead of a specific employee. The department rules select a person; that person must accept the task before the work counts as started. Declining requires a reason and comment: the task either moves to the next eligible person or returns for manual assignment. If candidates run out, assign someone manually. Check the acceptance status on the task card and refresh it after an error or conflict. In the create form, the Departments group normally shows only departments that accept these assignments. If none is eligible, the group stays visible and explains that intake is enabled on the department card under Task rules. If availability checking is temporarily unavailable, a department may remain in the list and be checked when selected: the absence of a marker is not a denial.

How to Choose Employees

When creating or editing a task, use participant search. It helps find an employee by first name, last name, or other available profile data.

The diagram shows how participant roles split responsibility: the assignee owns the result, co-executors own their parts, the requester accepts the work, and observers follow context.

1. Open the task in create or edit mode.
2. Go to the participants block.
3. Start typing the employee name in the search field for the needed role.
4. Select the employee from the candidate list.
5. If the list is grouped by departments, expand the needed department and check the team, avatar, or another visible profile cue.
6. Repeat the selection for co-executors and observers if they are really needed.
7. Save the task or changes.

Department grouping helps distinguish employees with the same name and choose people from the correct team. If several similar employees exist, look not only at the name, but also at the department, avatar, team, or another visible profile attribute.

How the Candidate List Works

Search updates while you type, so start with a short part of the first or last name and narrow the query only if the list is too long. Each role opens its own list: choose the assignee in the assignee row, co-executors in their row, and observers in theirs. This reduces the risk of moving a person into the wrong role.

If the list is split by departments, open only the needed group and verify the profile before selecting. Check not only the name, but also department, avatar, team, and hints such as "you" or "your employee." After selection, confirm that the person appeared in the intended role, not merely in the search results.

Keyboard navigation helps you move through the list quickly: type the query, move through options, select the right employee, and close the list if you change your mind. If the person is missing or cannot be selected, do not replace them with a same-name employee at random: first check the workgroup, permissions, and employee status.

Workgroup

The workgroup (project) shows where and in what context the task lives. It is selected at the top of the "Participants" block, above the requester row. Set the workgroup when the task belongs to a specific team, project, or workstream: this way the task lands in the right context, and access and participants are matched to that team.

If a participant is added after work has started, do not stop at adding them to a role. Leave a short comment: why the person is being involved, what has already been done, which files or checklist items to review, and what action is expected from them. This lets the new participant enter the task through context, not guesswork.

Role Check Before Saving

Before saving, check not only the names, but also how they are split by role. This matters most when similar employees appear in the list, some candidates are restricted by permissions, or the task is already in progress.

What to check	Healthy result	What to fix before saving
One assignee	The assignee role shows one current employee.	If there are several independent outcomes, split the work into related tasks.
Roles are not mixed	Requester (Reporter role), assignee, co-executors, and observers appear in separate role groups.	Move the person to the correct role instead of leaving them in the first group found.
No duplicates or old profiles	The selected person is an active employee with the expected department, avatar, or visible profile cue.	Remove an inactive profile, a namesake from another department, or a duplicate.
Restricted candidate is handled	It is clear why the person cannot be selected or does not appear in the list.	Choose another employee, request access, or split the task if access is limited by context.
Late change is explained	If a participant was added after work started, a comment explains the reason and expected action.	Add a short comment before saving or immediately after it.

This check replaces guessing from the visual list: the manager sees the result owner, the assignee understands their scope, and the new participant receives context inside the task.

The executor rows carry quiet context hints: on your own row you see a "you" marker, and a department manager sees a "your employee" marker on the rows of their subordinates. This helps you quickly understand where you are and who on the team reports to you, without opening a profile.

Unavailable Candidates and Permissions

Not every employee found in search is necessarily available for assignment. A candidate may be unavailable because of permissions, employee status, project restrictions, department, workgroup, or client context.

Participant search shows only employees who can be assigned tasks. As a result, some people will not appear in the candidate list for the assignee, co-executor, or observer role at all:

• external participants (guest and extranet accounts) — external access is not meant for executing internal tasks;
• disabled and inactive employees — they have no working profile for handling a task;
• employees without the permission to take tasks into work.

If the person you need is not in the list, this is not a search failure: check that they are an active internal employee with the permission to work with tasks. Hand the result to an external participant through an agreed channel, not through an assignment in the task.

If the needed employee does not appear in the list or cannot be selected:

• check whether the task belongs to a project, workgroup, client, or CRM record with restricted access;
• make sure the current employee profile is selected, not an old duplicate or inactive profile;
• check whether this person can see task materials and attached files;
• ask an administrator or workspace owner to configure access if participation is truly needed.

Do not bypass permission restrictions by adding the person as an observer or forwarding materials outside the task. A participant must have access to the working context inside LadVen OS, otherwise discussion and result verification split across different channels.

Before adding a new participant, check what context they will see with the task: description, comments, files, client, project, CRM links, and change history. If the person only needs one answer or a one-time approval, it is better to ask a question in a comment with a mention or create a separate related task with limited context than to open the whole work history to them.

How Not to Blur Responsibility

Before saving, ask three questions:

• who accepts the result;
• who is responsible for the task being completed;
• who performs separate parts but does not own the outcome.

If the second question produces several names, the task is formulated too broadly or roles are assigned incorrectly. Split the work into related tasks, assign one result owner, or clarify co-executor contributions in the checklist.

Signs of blurred responsibility:

• the assignee is formal, while real decisions are expected from another person;
• co-executors are added without a specific part of the work;
• observers are used as a mailing list;
• the requester cannot verify the result;
• the task describes several independent outcomes.

When responsibility starts spreading, do not solve it by adding new participants. Clarify the task result first. If there are several independent outcomes, split the work. If the outcome is one, choose one assignee and clearly describe everyone else's contribution.

If you are the assignee (lead executor) and remove yourself from the executors, LadVen OS will ask for confirmation: without other rights to the task, you may lose edit access and be left with viewing only. This protects you from accidentally losing access to your own work — confirm the removal deliberately and, if needed, assign a new assignee first.

Practical formula:

The assignee is responsible for the outcome.
A co-executor is responsible for their part.
The requester is responsible for clear expectations and acceptance.
An observer is responsible only for following the context themselves.

How to Do It in LadVen OS

1. Open the task in create or edit mode.
2. Check the requester: this person must understand the expected result and acceptance process.
3. Find the assignee through participant search.
4. Add co-executors if they have separate parts of the work.
5. Add observers if they need to see progress.
6. Check similar employees by department, team, or avatar.
7. Remove unnecessary participants and duplicates.
8. Save changes.

When editing an existing task, check the actual participant list in the task card after saving. If someone changed participants in parallel, refresh the task and make sure the saved composition matches the agreement.

What to Check Before Saving

• One assignee is selected.
• The requester can accept the result or return it for revision.
• Co-executors understand their part, and it is recorded in the task.
• Observers really need notifications.
• Participants are selected from current employees, not old duplicates.
• Every participant has access to the project, client, CRM record, files, and other task materials.
• The task does not include people added only "for visibility".

How to Verify the Result

After saving, open the task in view mode and check the participants block:

First read this block as the saved agreement, not as an edit form: who accepts the work, who owns the result, who helps, and who only observes. If you need to open participant search or change roles to answer that, the saved composition does not yet explain responsibility.

• requester, assignee, co-executors, and observers are displayed in the correct roles;
• the assignee is visible in the task list and assignee filters;
• the task appears in "my", "assigned", or "with my participation" views for the right people;
• participants can open the task and see the materials they need for work;
• if a participant was added after creation, they received context in the task, not only a verbal assignment.

If the list looks wrong, fix the roles immediately. The earlier unnecessary participants are removed or the correct assignee is assigned, the less confusion appears in comments, notifications, and statuses.

Before treating the participants block as ready, check the screen for:

• roles shown separately, not as one generic list of people;
• each participant has a clear name and enough profile context to distinguish a same-name person or duplicate;
• there is one assignee, and co-executors do not look like second owners of the result;
• observers are not mixed with executors and do not create the impression of extra responsibility;
• if someone cannot be selected or opened, the reason or next access step is clear.

For a manager, a correct result is not just a visible list of names. Each role should answer a management question: who accepts the work, who delivers the result, who performs their part, and who follows risks and decisions. If a participant is added later, the reason should be visible in a comment or checklist. If the assignee changes, the history should explain why responsibility moved and what state the work was handed over in.

After Changing the Assignee

Changing the assignee is a management event, not just a field correction. After the change, it must be clear why responsibility moved and in what state the work is being handed over.

A good handover includes:

• a short comment with the reason for the change;
• what has already been done and what remains;
• which files, checklists, and related tasks the new assignee should review;
• who will accept the result;
• whether there are risks around the deadline, planned time, or access.

Do not silently change the assignee in tasks that already have comments, files, a checklist, or client context. Otherwise the new result owner will have to reconstruct the history manually, and the manager will lose the explanation of why the work moved to another person.

Good Practices

• Assign one assignee to one verifiable result.
• Record a co-executor's contribution next to the work itself: in the description, checklist, or comment.
• Add observers only when they need to see progress, risks, and decisions during execution.
• When changing the assignee, leave a short comment explaining why responsibility moved and what has already been done.
• For independent results, create related tasks instead of expanding the co-executor list in one card.
• Check participant access to the client, project, CRM, documents, and files before work starts.
• If the task is client-related, keep the person responsible for client communication among participants, but do not make them responsible for another department's work.
• If a manager needs control, use observation and final comments, not formal assignment as assignee.
• Regularly remove people who no longer need the task context.
• In a role dispute, return to the acceptance criterion: who can verify the result and who must deliver it.

Common Mistakes

• assigning several effective assignees instead of one result owner;
• adding a co-executor without a clear part of the work;
• adding observers as a mass mailing list;
• selecting a same-name employee from another department;
• leaving an old or inactive employee profile;
• not checking participant access to files, project, client, or CRM context;
• changing the assignee without a comment explaining why responsibility moved;
• using observers to bypass access rights;
• not checking the final participant list after saving;
• creating one large task for several independent results.

What to Check After Selecting Participants

• In the task creation form, requester, assignee, co-executors, and observers are separated by role.
• Employee search helps distinguish same-name people by department, team, or avatar.
• The task keeps one assignee accountable for the result, while co-executors understand their parts of the work.
• After saving, the participant list in view mode matches the real responsibility.
• If a candidate is unavailable or restricted by permissions, the next step is clear: choose another person, request access, or split the task.
• In a client or project task, participants can open the linked materials needed for the work.

Mobile and narrow width

On a narrow screen, check that assignee and co-executor rows remain readable: the lead executor has a distinct role label, co-executors do not look like a second owner, and action buttons are available after focus. Observers appear as separate compact chips rather than blending into the executor rows. Open a role picker and make sure its popover stays within the card: the list may scroll vertically, long names may be visually truncated but must remain available through their label or focus. If a candidate or action does not fit, scroll the list itself, narrow the query, or follow the clear access next step; do not scroll the page horizontally.

Related sections

• Create a Task
• Task Card
• Task Fields and Work Context
• Add a Checklist
• Attach Files to a Task
• Task Comments
• Review and Close a Task
• Errors, Limits, and Unavailable Actions