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.