> For the complete documentation index, see [llms.txt](https://docs.smt-x.com/smtx-online-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.smt-x.com/smtx-online-documentation/fulfillment-platform/pools.md).

# Pools

## Pools in SMTX: Access Control, UI Configuration, and Use Cases

### What is a Pool?

A **pool** in SMTX is a structural mechanism used to:

* Isolate ticket data and restrict access
* Configure how tickets behave and are presented in the UI
* Define context-specific email behavior for ticketing events

Pools serve a similar function to *mandants* in SAP: they act as isolated containers that group tickets and tailor the user experience around them.

***

### Why Use Pools?

Pools are primarily used to:

* **Control access**: Only users with explicit rights to a pool can view or interact with the tickets within it.
* **Customize configuration**: Per pool, admins can define:
  * Which ticket fields are visible, editable, or required
  * Which email templates are used per event (e.g., assignment, updates, progress)
  * How the UI behaves for the ticketing interface

***

### Role-Based Access to Pools

#### Rights Are Granted via Roles

Users do **not** get access to pools directly. Instead:

* **Roles** define the access rights (e.g., `Read`, `Limited`, `Write`) per pool.
* **Users receive one or more roles**, which in turn grant rights to one or more pools.

> Rights are always **cumulative**: if a user has multiple roles, the permissions across all assigned roles and pools are merged — rights are **never removed** by having multiple roles.

#### Example

If a user has:

* `Read` rights to the *Customer tickets* pool via role A
* `Write` rights to the *Integrations* pool via role B

Then the user can:

* View tickets in *Customer tickets*
* Edit and update tickets in *Integrations*

***

### Pool Settings and Configuration Options

Pools offer two main configuration tabs:

#### 1. **Ticketing Email Templates**

You can define specific templates for events such as:

* Ticket assignment (to group or person)
* Status updates
* Task assignment
* Progress messages (Private, Public, Question)
* Changes to planned delivery date

If no custom template is set, the **default system templates** are used.

#### 2. **Ticketing UI Settings**

Within the UI configuration tab, you can:

* Set visibility for each field (e.g., `Show`, `Hide`, or inherit default)
* Define rights (e.g., `Read only`, `Read and write`)
* Mark fields as required, optionally only at ticket closure

These settings apply to both **standard** fields (e.g., *Description*, *Information*, *Solution*) and **custom** fields (e.g., *RFC Effort*, *ExternalAcceptance*).

> ⚠️ UI and email settings are **not inherited** and are fully managed per pool.

***

### Pools vs. Groups: Purpose, Interaction, and Key Differences

In SMTX, **groups** and **pools** are two distinct mechanisms with different purposes. They are not interchangeable — both are needed and used together.

#### ▶️ Groups: Assignment and Responsibility

Groups are primarily used to:

* Assign tickets to a **team or functional unit**
* Route tickets to a **specific person** within a group (e.g., support queue)

Users who belong to a group can **see all tickets assigned to their group**, regardless of pool configuration.

> ⚠️ However, group membership **does not restrict visibility** — it simply enables ticket assignment and ownership management.

#### ▶️ Pools: Access Control and Visibility

Pools control **who can see or interact with a ticket** — even if the ticket is not assigned to their group.

* If a user has rights to a pool (via a role), they can access **all tickets in that pool**
* If not, the ticket is **completely hidden** from them
* Admins are **also restricted** by pool access (unless they have roles that include those pools)

#### 🧠 Common Use Case: Private Queues

> *"We want a group to have their own ticket queue that no one else — not even Admin — can see."*

This is **exactly** what pools are for:

* You assign tickets to a pool dedicated to that group.
* Only users with rights to that pool (via roles) will see the tickets.
* Even if Admins exist elsewhere in the system, they won't see these tickets unless explicitly granted access to the pool.

Be cautious: if a ticket is **reassigned to another group**, and that group’s default pool differs, the ticket may switch pools — potentially changing visibility.

#### 🧩 Pro Tip: Visual Pool Indicators

You can assign **color codes** to pools for quick visual identification. This helps users understand at a glance which context (e.g., internal team, confidential queue, etc.) a ticket belongs to.

***

### Summary: Groups vs Pools

| Feature            | Groups                                | Pools                            |
| ------------------ | ------------------------------------- | -------------------------------- |
| Main purpose       | Assigning responsibility              | Controlling visibility/access    |
| Visibility control | Limited — all group members see       | Strong — only users with roles   |
| Ticket ownership   | Yes                                   | No (ownership handled via group) |
| Admin access       | Unrestricted by default               | Must have role in pool           |
| Use together?      | ✅ Yes — groups assign, pools restrict |                                  |

***

### Common Usage Scenarios

#### 1. **Security: Limit Ticket Visibility**

Pools allow ticket visibility to be strictly controlled. Without pools, ticket access depends on group assignment. With pools, access is based on explicit pool rights, enabling:

* Broader access to tickets **outside group assignments**
* Tighter segmentation across departments or support levels

#### 2. **Isolate Technical Tickets**

A pool like `Integrations` can be used to store system or interface-related tickets. Only admins may have access to that pool, shielding regular users from unnecessary or technical details.

#### 3. **Field Customization Per Context**

Pools allow customizing ticket fields per use case. For instance, in the `Finance` pool, only a subset of fields might be editable, while in `Customer tickets`, more descriptive fields are required.

***

### Limitations and Design Principles

* There are **no global defaults** for pools — each pool has its own isolated settings.
* **Settings cannot be overridden per user or per role**; all configuration is handled at the pool level.
* Pools are intentionally isolated to support clean separation of workflows and responsibilities.

***

### Summary

| Feature                      | Behavior                                                     |
| ---------------------------- | ------------------------------------------------------------ |
| Access control               | Managed via roles per pool                                   |
| Rights merging               | Additive across all roles                                    |
| Group linkage                | Optional default pool per group (for ticket assignment only) |
| UI and field configuration   | Per pool, not overrideable per user or role                  |
| Email template customization | Per pool; defaults apply if unspecified                      |
| Primary benefit              | Segregated visibility and tailored ticket behavior           |

***

By leveraging pools, SMTX offers a flexible and secure framework to manage ticket visibility, behavior, and ownership — ensuring each user sees only what they need, in the way that makes the most sense for their role.