Company and teams
Company sections define the working structure of LadVen OS: who works in the portal, which departments they belong to, which workgroups they run, and which data they can access. This structure affects tasks, CRM, documents, chat, calendar, workflows, Disk, and reporting.
Where to work
- Company (
/company) - entry point to departments, employees, access rules, and portal settings. - Employees (
/users) - user list, search, profiles, activity, language, timezone, and rights. - Departments (
/departments) - organization tree, managers, members, task assignment rules, and work transfer between departments. - Workgroups (
/projects) - project teams, owners, roles, states, and participants. - Workgroup card (
/projects/:projectId) - a project workspace with overview, tasks, activity, files, documents, links, discussions, relations, and settings.
Available actions depend on the role. Employees see only the structure and projects available to them. Administrators manage members, access, and rules. Workgroup owners and moderators manage their group.
How structure affects work
The company structure is not just a directory. It defines who can assign work down, up, or across departments, which responsible people appear in CRM, which team context is used for documents and files, who receives workflow tasks, and how reports group workload by departments, people, and projects.
Before tuning access or workflows, make sure employees, departments, and workgroups reflect real responsibility. Outdated structure makes permissions and reports misleading.
Employees
The Employees page shows people and service users available in the portal. You can search by name, login, email, phone, or position, see the role and status, and open the user for editing.
In the directory, a birthday badge appears next to an employee's avatar on their birthday — a quiet hint for the team to congratulate a colleague. The badge is visible only on the day itself, relies on the birth date from the profile, and does not show the year. Whether badges show in the directory is each user's personal setting (the "Birthdays" toggle), not a company-wide policy. The same badge is visible when picking participants in a department card; in chats, tasks, and CRM it does not show yet.
Administrators manage the user login, email, phone, name, position, birth date (personal data, for the birthday badge in the directory), interface language, timezone, active state, admin flag, password, and a rights summary for Tasks and CRM.
Create users with work contacts and a clear role. If a person temporarily stops using the portal, disable the account before considering deletion. Delete a user only after confirming that tasks, documents, reports, and process links will keep their history intact. Do not use admin rights as a shortcut for a single access issue: first check department membership, workgroup role, personal policy, and module settings.
Departments
Departments describe the management structure: reporting lines, department heads, and how work moves between levels. Keep every department with a clear name, real manager, current members, correct tree position, active state, and task assignment rules.
If an employee moves to another department, update the structure before assigning new tasks or workflow work. If a department is closed, review active tasks, projects, documents, and access rules first.
Department task rules
Departments can define task assignment directions:
- downward - work can be assigned to subordinate departments;
- upward - work can be escalated to managers;
- sideways - work can move to related departments;
- inside department - work stays inside the same team.
Use presets as a starting point and verify them on a real scenario. Sales often needs upward escalation and cross-department work; production often needs downward assignment and manager control; a small service team can stay inside one department. Record a clear change reason when saving local rules.
Workgroups
A workgroup brings people together around a project, client, product, internal initiative, or temporary team. In the catalog you can search groups, create new ones, see the owner, your role, status, and open the group card.
Configure the name, code, description, subject, owner, project or Scrum flags, visibility, open state, closed or archived state, and members with owner, moderator, member, or guest roles.
Use workgroups when you need a project context separate from the permanent organization, people from different departments, shared tasks, CRM items, documents, files, and discussions, or a preserved history after the project ends. Do not create a workgroup for every small task.
Workgroup card
The workgroup card is the project workspace. Use it to keep the context in one place:
- Overview - owner, description, members, and key facts.
- Activity - recent events and items that need attention.
- Tasks - work created and controlled in the group context.
- Files and documents - materials, templates, packages, and deliverables.
- Links - external resources the team needs.
- Discussions - decisions and working agreements.
- Relations - connected clients, contacts, deals, or other entities.
- Settings - description, members, and workspace rules.
For public screenshots, use only demo projects, neutral people, safe files, and links without private URLs.
Access and responsibility
Rights must reflect real responsibility. Before changing access, answer why the person needs it, which scope it belongs to, and who owns the consequences. If a person sees too much or too little after a change, check departments, workgroup membership, personal policies, and module settings.
Screenshot safety
Documentation screenshots must contain only demo employees, training departments, demo projects, safe files, links without tokens or private domains, and a fully localized interface. Do not publish screenshots with real emails, phones, avatars, private files, raw errors, technical fields, or mixed languages.
Good practices
- Keep the employee list current.
- Separate departments from project workgroups.
- Assign an accountable owner to every workgroup.
- Recheck access after structure changes.
- Use clear department and group names.
- Archive completed groups when history is still needed; delete them only when the history is no longer needed for reporting.
- Check employees and departments before launching workflows.
Common mistakes
- Creating a department without a manager.
- Adding someone to a project without checking their role and document visibility.
- Granting admin rights instead of fixing the scope.
- Deleting users or groups before checking history.
- Using real client projects or employees in screenshots.
Related scenarios