Service Configurations

Service Configuration covers how support tickets get automatically routed to the right person, how tickets get classified, and how Ticket and Sub-Ticket IDs are generated — the setup work that keeps your service operation running smoothly without manual intervention on every incoming request.

Account Team (Related Person)

Found as a tab inside any Account record, Account Team lets you assign specific employees as the dedicated point of contact for that customer — and this assignment is what the Ticket Assignment Engine checks first when a new ticket comes in.

What You’ll See

A grid showing each assigned employee’s Name, Function (Sales or Service), Personnel Role, Country, Region, Organization View, Sales Channel (their email address), Territory, and whether they’re the Default for that combination.

Good to Know

• Read-only roles (Service Manager, Service Rep) can view the grid but have no New, Edit, or Delete controls
• Admin and Consultant have full CRUD access
• For a given Account and Channel, only one employee can be marked Default — trying to set a second one is blocked until you uncheck the existing one

How Ticket Auto-Assignment Uses This

When a ticket comes in (especially via email), the system runs this logic before anything else:

1. Match the sender’s email to a Contact
2. If found, look up that Contact’s linked Account
3. Check the Account Team for entries where Function = Service and Channel matches the inbound email address
4. If exactly one match, assign that employee; if multiple match, assign whoever is marked Default
5. Auto-populate the ticket’s Service Organization, Support Team, Channel, and Employee Responsible (the ticket owner) from that employee’s record

If any step fails — no Contact match, no linked Account, or no matching Account Team entry — the system falls back to the standard Ticket Assignment Rules instead. This same logic works identically whether it’s a true B2B setup (separate Contact and Account) or B2C (where Contact and Account are the same record).

Ticket Assignment Rules

The fallback layer that handles routing whenever Account Team assignment doesn’t apply — a sequence of conditional rules evaluated top to bottom.

How It Works

Each rule is a row in a grid, built from optional condition fields — Channel Type, Channel ID, Category 1/2/3, Product Category, Product Type, Product Priority, Territory, Business Unit — plus two assignment fields: Responsible Team and Owner.

• Clicking any condition field opens a popup where you choose an Operator (Equal, Not Equal, Contains) and a value; leaving it blank means that condition matches anything
• Assignment fields (Team, Owner) just need a value selected from a searchable list — no operator

Matching Logic

Rules are evaluated in the order they appear (by Sequence). For each rule, every non-blank condition must match — this is AND logic within a row. The first fully-matching rule wins, and its Team/Owner get applied immediately; no further rules are checked. If nothing matches, the ticket stays unassigned.

Good to Know

• Account Team always takes priority — if the ticket’s Account has a matching Account Team entry, these rules are never even evaluated
• Only Admin and Consultant can add, edit, delete, or reorder rules — Service Manager and Service Rep see a fully read-only grid

Ticket Categories

A configurable, three-level hierarchy used to classify tickets by issue type — think of it as a catalog you build once and activate.

Category Sets

Everything starts with a Category Set — a named container (e.g., “2025 Ticket Categories”) that holds an entire L1 → L2 → L3 hierarchy.

• Catalog Name is mandatory and must be unique
• Status starts as In Preparation by default, and can move to Active or Inactive
• Only one Category Set can be Active at a time — activating a new one automatically deactivates whichever was Active before

Building the Hierarchy

Once a set exists, you build its Ticket Catalog tab:

• Level 1 – the top of the hierarchy; needs a Category ID (alphanumeric, max 5 characters, unique within the set) and Name
• Level 2 – requires selecting an existing L1 as its parent
• Level 3 – requires selecting an existing L2 as its parent; its L1 grandparent is shown automatically, read-only

Good to Know

• The parent of an L2 or L3 category can never be changed once created — if the hierarchy needs restructuring, categories need to be deleted and recreated
• Deleting cascades downward: removing an L1 also removes every L2 and L3 beneath it; removing an L2 takes its L3 children with it. You’ll get a confirmation warning before this happens
• A category at any level can’t be deleted if it’s currently used in any ticket
• Activating a set validates the whole hierarchy first — every L2 must have a valid L1 parent, and every L3 must have a valid L2 parent, or activation is blocked
• Status can only move Active → Inactive, never directly back to In Preparation — if you need to revert a set to preparation, it has to pass through Inactive first

Change History

Every field-level change — to the catalog name, status, or any category at any level — is captured here automatically, read-only in both View and Edit mode, shown most-recent-first.

Ticket & Sub-Ticket Number Ranges

Two separate tabs — one for Tickets, one for Sub-Tickets — each governing how IDs are generated, following the same interval-based pattern used elsewhere in GEMS CRM.

What You’ll See

• Description, Begin/End Number, Current, Status, and Type (Automatic or Manual) per range
• Edit, Clone, and Delete actions per row

Creating or Editing a Range

• Description, Start Number, End Number, and Total Length are all mandatory
• Range Type (Automatic/Manual) can’t be changed once a range is created
• Optional Prefix, plus Reset Rule and an Auto Increment toggle (visible only for Automatic ranges)
• A live preview shows the exact generated ID format as you configure

Good to Know

• Clone copies an existing range’s settings into a new one — you’ll need to change at least the Description before saving, since it’s still treated as a brand-new range
• Deletion is blocked if any ticket or sub-ticket has already been created using an ID from that range
• Numeric intervals can’t overlap with another range of the same object type, regardless of prefix
• When an Automatic range’s Current Number reaches its End Number, the range is exhausted — further ticket creation is blocked until a new range is configured or the existing one is extended
• Admin and Consultant have full access; Service Manager and Service Rep can view ranges but can’t create, edit, clone, or delete them