# 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.smt-x.com/smtx-online-documentation/fulfillment-platform/pools.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.