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 what data they can access. This structure affects tasks, CRM, documents, chats, calendar, workflows, and reports.
Where to Find It
Main sections:
- Company (
/company) - quick entry to departments, employees, access rights, and portal settings; - Employees (
/users) - users, profiles, activity, language, time zone, and permissions; - Departments (
/departments) - org structure, managers, members, and cross-department task rules; - Workgroups (
/projects,/projects/:projectId) - teams around a project, customer, direction, or internal initiative.
Available actions depend on role. A regular employee may see only their part of the structure; an administrator manages members, roles, and rights.
Employees
An employee profile is not only a login record. It tells the team who owns work, how to contact them, where they sit in the organization, and which actions are available.
Before adding or editing an employee, check work name, contact details, active status, departments, position, language, time zone, admin rights, and module access.
Do not grant administrator rights just to solve one access issue. Configure the role or scope so it matches real responsibility.
Departments
Departments describe the management structure: reporting lines, department heads, and how work can move between levels. This matters for task assignment, escalation, time planning, and data access.
Keep each department name, head, and member list current. If a person moves to another department, update the structure before new processes start using the old one.
Workgroups and Projects
A workgroup brings people together around specific work: a project, customer, product, internal initiative, or temporary team. It can control members, roles, visibility, and state.
Use workgroups when you need cross-department access, a shared context for tasks, CRM, documents, and chats, or a clear owner for a project space.
Do not create a workgroup for every small task. If the work is short and does not need its own member list, use a task or CRM record.
Access and Responsibility
Permissions should mirror responsibility. A user needs enough access to do the work, but not more. Before changing rights, define why access is needed, which scope it belongs to, and who owns the result.
If a user sees too much data or cannot see required work after a change, check departments, workgroups, and module policies.