Organizational Structure Entity for Function-Based Assignment and Process Ownership

[partomas]

Hi EspoCRM Team,

I would like to suggest introducing a native Organizational Structure entity that could be used as a core layer for process ownership and work assignment.

Currently in EspoCRM, most processes are centered around Users or Teams. While this works well for permissions and collaboration, it doesn’t fully represent how many organizations structure responsibilities internally.

In many companies, work is not owned by a specific person first — it belongs to a function or position within the organizational structure. The person occupying that role may change, but the responsibility remains stable.

For example:

• Leads may first belong to a Consultant function
• Later they move to a Sales function
• The actual users performing those roles may change over time

From a process architecture perspective, it would be very useful if records could be assigned to organizational functions or positions, rather than always to specific users. Proposed Concept


Introduce a new entity such as:

Organizational Structure

with hierarchical nodes representing things like:

• Departments
• Teams
• Positions
• Functions

Each node could:

• contain assigned users
• define a primary responsible user
• support substitutes or temporary replacements
• inherit hierarchy visibility Assignment Model


Records (Leads, Cases, Tasks, Opportunities, custom entities) could then support:

• Assigned Organizational Node
• Current Executor (User)

This would separate:

Business Responsibility
from
Current Execution Practical Examples


Lead Processing

A lead is assigned to the Consultant node in the structure.
Any active consultant can pick it up or it can be auto-assigned.

Routine Tasks

Recurring tasks belong to a role or position, not to a specific person.
If the person leaves or is on vacation, the task still belongs to the role.

Temporary Substitution

If a user becomes unavailable, tasks and responsibilities could automatically shift to another user within the same organizational node. Why Teams Alone May Not Solve This


Teams work well for access control and collaboration, but they don’t fully represent:

• hierarchical organizational structure
• role-based ownership
• responsibility continuity when people change
• routine operational tasks tied to roles Business Value


Such a structure could significantly help organizations with:

• process handoffs
• shift work
• shared responsibilities
• support teams
• operational workflows
• recurring responsibilities Concept Reference


A similar business concept can be seen in systems that organize work around organizational structure and functional roles.

This video demonstrates the type of organizational perspective I mean:

https://youtu.be/npX0J_Z6jTk?si=3fi8ZdL-Opg5RvtY

The idea is not to replicate another product, but to introduce a structural layer that reflects how responsibilities exist inside organizations.

Even an initial version supporting Tasks, Leads, and Cases would already be very valuable.

Would something like an Organizational Structure entity make sense as a future feature or extension point in EspoCRM?

Thanks for considering the idea.

[partomas]

**Org Structure Module — Task Assignment by Position, Not by User**


### The Problem

EspoCRM assigns records (Tasks, Leads, Cases) to `User` or `Team`. This creates a hard dependency on specific people and causes three distinct problems:

**1. Assignments break when people change.**
When a user leaves, goes on vacation, or a role is split between people — every assignment tied to them breaks silently. There is no way to say "this task belongs to whoever runs the Accounting function" — you can only say "this task belongs to Maria."

**2. People don't know who to assign to across departments.**
In any organization beyond 15–20 people, employees in one department often have no idea which specific person in another department handles a particular function. A project manager in Production needs to request PR materials — but who exactly in Marketing does that? Is it Anna? Or did she move to a different role last month? The user is forced to either guess, ask around, or escalate to a manager just to figure out the right person.

With position-based assignment, this problem disappears entirely. You assign to "PR Materials Section" or "Marketing — Promotion Division" — you don't need to know which person currently sits there. The system resolves it.

**3. Teams don't solve either problem.**
Teams are flat (no hierarchy), have no concept of responsibility vs. access, no escalation logic, no vacancy handling, and no way to express "this is the unit responsible for X output."

---

### What We Need

A flexible, self-referencing hierarchical entity where clients define their own organizational tree — any depth, any naming. A 5-person startup might have 8 nodes. A 500-person company might have 100. The system doesn't dictate structure — the client builds it.

When assigning a task, the user browses or searches the org tree — not a flat list of 200 usernames. They pick the *function*, not the person. The system figures out the rest.

---

### Data Model

**1. `OrgUnit` — core entity (self-referencing tree)**

```
org_unit
├── id PK
├── parent_id FK → org_unit (nullable, root = NULL)
├── name varchar — client names it whatever they want
├── level_label varchar — freeform: "Board", "HQ", "Department",
│ "Division", "Section", "Position", "Team",
│ or any custom label the client needs
├── expected_output text — what this unit is supposed to produce
├── sort_order int — sibling ordering within parent
├── status enum: Active | Vacancy | Planned | Inactive

```

Key point: `level_label` is a **freeform string**, not a fixed enum. One client may use "Board → HQ → Department → Division → Section." Another may use "Region → Branch → Team → Role." The tree depth is unlimited — the hierarchy is defined purely by `parent_id` chains.

**2. `UserOrgUnit` — junction (M:N, users ↔ org units)**

```
user_org_unit
├── id PK
├── user_id FK → User
├── org_unit_id FK → OrgUnit
├── role enum: Primary | Backup | Temporary
├── valid_from date (nullable)
├── valid_to date (nullable)
└── is_active bool (derived or explicit)
```

One user can hold multiple org unit positions (common in small companies — the CEO is also Head of Sales). One org unit can have multiple users (shared role, shift work).

**3. Assignment field on existing entities**

Add optional `assigned_org_unit_id` (FK → OrgUnit) to Tasks (V1), later to Leads, Cases, Opportunities.

This field coexists with `assigned_user_id` — not replaces it. When `assigned_org_unit_id` is set, the system resolves the current executor:

```
Resolve(org_unit_id):
1. Find user_org_unit WHERE org_unit_id = X
AND role = 'Primary' AND is_active = true
2. If found → return user(s)
3. If not → find role = 'Backup' AND is_active = true
4. If not → Resolve(org_unit.parent_id) // escalate up the tree
5. If root reached and nobody found → flag as unassigned
```

---

### UI Requirements (V1, minimal)

**OrgUnit management screen:**
- Tree view (collapsible) showing the full hierarchy
- Drag-and-drop to reorder / reparent nodes
- Inline add: click "+" on any node to add a child
- Each node shows: name, level_label, status badge, assigned user count
- Node detail panel: expected_output, linked users with roles

**On Task (and later other entities):**
- New field: "Assigned Org Unit" — lookup with tree-style picker or searchable dropdown (user types "PR" and sees matching org units, not people)
- When selected, "Current Executor" auto-resolves and displays (read-only)
- If no executor resolved → visual warning: "⚠ No active user in this position"

---

### Client Flexibility — This Is Critical

The module must NOT hardcode organizational levels or enforce a specific methodology. Different clients will need completely different structures:

```
Example A (manufacturing): Example B (consulting):
Board of Directors Managing Partners
└─ HQ ├─ Practice: Strategy
├─ Production Department │ ├─ Senior Consultants
│ ├─ Planning Division │ └─ Analysts
│ ├─ Supply Division ├─ Practice: Operations
│└─ Assembly Section └─ Back Office
├─ Finance Department ├─ Finance
└─ Sales Department └─ HR
```

Both are valid. The system stores them identically — just `parent_id` chains with freeform `level_label` and `name`. No predefined depth limits, no mandatory levels.

---

### Scope

**V1 (this task):**
- OrgUnit entity with self-referencing hierarchy
- UserOrgUnit M:N junction with role field
- Tree management UI
- `assigned_org_unit_id` field on Task entity
- Resolution logic (Primary → Backup → Escalate to parent)

**Later (not in scope now):**
- Assignment field on Leads, Cases, Opportunities
- Workflow integration (BPM triggers by org unit)
- Structure-based dashboards and reporting
- Import/export (CSV/YAML)
- API endpoints for external integrations
- Task-level roles beyond executor (e.g., Approver, Reviewer mapped to org units — once the core structure exists, these can be added as custom link fields pointing to OrgUnit, enabling flows like "Executor = Sales Section, Approver = Sales Division Head")

---

### Seed Data

We have a ready Excel template with a sample org structure (7 departments, 21 divisions, ~70 sections) that can be used for testing and demo purposes. Can provide on request. yuri I know it's againts a forum rules to ping you directly, so I'm sorry for that, but anyway can you look is it make sence?

[yuri]

Currently we don't have capacity to consider such big core features. From what I understood it would be a huge endevour to implement. We've been delivering quite a lot for a while. We'd better focus on polishing and improving existing features for a while than extend core features so drastically (record assignment I'd consider as a core feature). Our backlog for features and improvements is already huge.