Note de lansare 2026.2

Până acum, fiecare coadă distribuia propriul canal și nimic nu putea răspunde la o întrebare simplă: care este cel mai important lucru din centrul de contact chiar acum? Un e-mail VIP nu putea trece înaintea unui apel în așteptare. Un termen limită la trei ore distanță nu putea escalada nimic. Restanțele nu puteau fi amestecate cu traficul live. Daktela 2026.2 răspunde la această întrebare, iar aproape tot restul acestei versiuni există ca să susțină răspunsul.

Priority Flows este coada unificată a Daktela – funcționalitatea vândută și sub numele de dirijare omnichannel sau coadă universală. O singură pâlnie în care intră fiecare canal, un singur număr care decide ce urmează și o evidență a felului în care s-a luat fiecare decizie.

Nimic din toate acestea nu se impune nimănui. Împingerea muncii către oameni o pornești tu, iar dacă nu schimbi nimic, nu se schimbă nimic. La final găsești ce face actualizarea de la sine și ce lasă neatins.

Cât de departe mergi depinde de tine

Trei moduri de a lucra cu tichetele

Fiecare nivel îl continuă pe cel dinainte. Oprește-te unde îi convine echipei – iar echipe diferite de pe aceeași instanță pot rămâne la niveluri diferite.

Nivelul 1

Manual

Ce ai astăzi. Nimic nu este împins și nimic nu va fi, până când nu creezi o coadă de tichete sau o regulă.

Nivelul 2

Coadă de tichete

Distribuție prin împingere, prioritatea de bază a cozii și creșterea ei în timp în funcție de SLA. Fără reguli de scris.

Nivelul 3

Priority Flows

Deasupra, motorul de reguli cu punctaj: cântărește munca din fiecare canal pe o singură scară, cu raportare și pistă de audit completă.

Distribuție unificată

Cum funcționează coada unică

Priority Flows punctează munca. Cozile de tichete și cozile de canal existente o primesc. Regulile de distribuție a tichetelor decid care tichete intră în distribuție. Matricea de distribuție decide cât ține un agent deodată. Rotația canalelor decide ce fel de muncă îi vine la rând. O singură unitate de muncă – un apel, un chat, un mesaj, un tichet – este o activitate.

Funcționalitate nouă

Priority Flows

Un Priority Flow dă fiecărui element sosit un punctaj de pornire, apoi îi aplică o listă ordonată de reguli – un client VIP adaugă 300, un termen limită în mai puțin de 24 de ore adaugă 220. Fiecare regulă potrivită adaugă la totalul curent, așa că prioritatea se construiește pas cu pas, nu se alege dintr-o listă.

Prioritatea se compară global: agentului i se oferă elementul cu cel mai mare punctaj din toate cozile pe care le deservește, indiferent de canalul pe care a sosit – în limitele matricei de distribuție, ale rangului său pe acea coadă și ale strategiei prin care coada își alege agentul.

Numerele de aici sunt exemple, nu valori implicite. Tu stabilești cât valorează un apel live față de un tichet vechi de două zile.

Un tichet printr-un Priority Flow

Intră în Priority Flow cu prioritatea lui implicită	100
Regula 1 – contactul se află în baza de date VIP	+300
Regula 2 – primul răspuns întârziat · fără potrivire	—
Regula 3 – termen limită SLA în mai puțin de 24 de ore	+220
Punctajul cu care ajunge la coadă	620

Un tichet trimis direct în aceeași coadă, fără Priority Flow, ar porni de la prioritatea proprie a cozii – să zicem 250 – și ar urca pe măsură ce așteaptă. Când se eliberează un agent, primește răspuns cel cu numărul mai mare.

Cum este alimentat un Priority Flow

Apelurile, chaturile și mesajele ajung într-un Priority Flow prin dirijarea de intrare a canalului, unde indici Priority Flow-ul ca următoare destinație. Tichetele ajung acolo printr-o regulă de distribuție a tichetelor – inclusiv fiecare tichet creat dintr-un e-mail, pentru că un e-mail devine mai întâi tichet, iar dirijarea lui de e-mail funcționează exact ca astăzi. Orice sistem din afara Daktela poate pune un tichet într-un Priority Flow prin API.

Un element pornește de la prioritatea implicită a Priority Flow-ului, de la prioritatea de intrare aleasă de regula care l-a trimis sau, dacă niciun Priority Flow nu a fost implicat, de la prioritatea proprie a cozii. De acolo preia ștafeta creșterea în timp configurată pe coadă, de îndată ce elementul începe să aștepte. Pașii de configurare se găsesc în documentație.

Prioritatea și punctajul sunt același număr. Prioritatea este ce setezi tu; punctajul este ce poartă elementul după ce regulile și așteptarea și-au făcut treaba.

Funcționalitate nouă

Cozile de tichete

Un nou tip de coadă, care împinge tichetele către agenți în loc să aștepte ca cineva să le aleagă dintr-o vizualizare. Dacă ai deja o coadă de apel sau de chat, știi să o administrezi și pe aceasta – păstrează aceleași setări: cum alege un agent, cum se conectează agenții, orele de lucru, timpul de finalizare, dacă se încearcă mai întâi ultimul agent sau proprietarul tichetului și unde ajunge munca dacă așteaptă prea mult.

O coadă de tichete funcționează și ca destinație a unui Priority Flow: un tichet sosit dintr-un Priority Flow își păstrează punctajul și se intercalează cu tichetele puse direct în coadă printr-o simplă comparație de numere.

Funcționalitate nouă

Cum crește punctajul unui element în așteptare

Punctajele cresc în continuare cât timp un element așteaptă, așa că nimic nu se scufundă în tăcere la fundul listei. Pe o coadă de tichete, creșterea se face pe trepte, în raport cu termenul limită SLA al tichetului: o valoare de bază cât timp se încadrează în SLA, una sau mai multe trepte pe măsură ce termenul se apropie – la cinci zile distanță poate adăuga 500 pe zi, la o zi distanță 800 la fiecare douăsprezece ore – și un ritm separat după ce termenul a trecut. Orice alt tip de coadă primește în schimb un singur increment fix pe perioadă.

Creșterea în timp se setează pe coadă, nu pe Priority Flow, așa că se aplică indiferent dacă a fost sau nu implicat vreunul. Două cozi care cresc punctajul în ritmuri diferite își vor lăsa elementele să se întreacă reciproc în timp – bine de știut înainte de a stabili ritmurile.

Funcționalitate nouă

Regulile de distribuție a tichetelor

Un singur loc în care decizi dacă un tichet intră în distribuție, unde ajunge și cu ce prioritate. O regulă filtrează după evenimente de tichet, timp scurs și câmpuri de tichet sau CRM – un e-mail nou de intrare, un termen limită în decurs de o oră, un tichet neatins de când a fost setat ultima dată un anumit câmp de dată, o schimbare de stare care chiar s-a produs. Condițiile stau în două grupuri: tot ce se află în primul trebuie să fie adevărat, plus cel puțin o condiție din al doilea.

Un serviciu de fundal reverifică regulile la fiecare 30 de secunde, așa că un tichet cu termenul limită aproape de expirare escaladează la timp, fără să fie nevoie ca cineva să îl deschidă.

De ce există două seturi de reguli

La regulile de distribuție, prima care se potrivește decide totul, inclusiv dacă tichetul intră sau nu în distribuție. În interiorul unui Priority Flow, fiecare regulă care se potrivește adaugă la punctaj, iar o regulă poate și fixa unde ajunge elementul. Cele două rulează una după alta: regula stabilește punctajul cu care sosește tichetul, iar Priority Flow-ul adaugă peste el.

E-mailul nu sosește niciodată ca un conector de canal: un e-mail devine mai întâi tichet, dirijarea cozii lui de e-mail funcționează ca astăzi, iar regulile de tichet decid după aceea. Înregistrările de campanie urmează într-o actualizare minoră.

Reproiectat

Matricea de distribuție, în numere simple

Câtă muncă ține un agent deodată și care canale le blochează pe care se citește acum în numere întregi, nu într-o grilă: câte un card pentru fiecare canal de intrare, „când sosește un apel…”. Un card spune Maximum 3 deodată și blochează un apel nou dacă agentul are deja două sau mai multe chaturi web deschise, cu presetări per card pentru cele două cazuri obișnuite: blocat de orice altă muncă deschisă sau niciodată blocat.

Se schimbă ce vezi, nu ce se întâmplă. Setările tale existente se transferă neatinse, efectul asupra fiecărui agent este identic și nu ai nimic de reconfigurat.

Centrul de contact are acum o singură matrice globală, care există întotdeauna – baza la care revine fiecare agent – iar un profil fie o moștenește, fie o suprascrie explicit în propria filă Matrice de distribuție. Modificările sunt reținute și marcate până la salvare, iar editarea valorii globale implicite cere permisiunea Setări globale; fără ea, același ecran se deschide în modul numai citire.

Funcționalitate nouă

Rotația canalelor pentru agenți

„După două apeluri la rând, redu-i acestui agent șansele de a primi al treilea.” Rotația modelează succesiunea muncii unui agent; matricea de distribuție stabilește cât anume ține el deodată. Regulile stau în fila Rotație canale a profilului: după un număr stabilit de interacțiuni consecutive de același fel – un singur canal sau o categorie întreagă, de pildă orice chat – rangul agentului pentru acel fel de muncă scade cu o valoare pe care o alegi pe o scară de la 1 la 10, așa că are mai multe șanse să îi vină la rând altceva.

Este o înclinare, niciodată o blocare: un agent depriorizat preia totuși elementul dacă nu este liber nimeni mai potrivit, iar munca aflată în risc de încălcare a SLA câștigă întotdeauna. Rotația este oprită până când un profil o activează; nu există o valoare implicită la nivelul întregului centru de contact.

În curând

Înregistrările de campanie intră în coadă

Un script de apel se va asocia cu un Priority Flow în locul unei singure cozi de campanie. Înregistrările intră în pâlnie pe măsură ce devin scadente, primesc punctaj în funcție de baza de date, de atributele înregistrării și de cât de mult au întârziat, iar Priority Flow-ul alege coada de ieșire. Tipul de campanie al cozii stabilește în continuare cum se apelează; Priority Flow-ul decide în ce coadă, când și cine.

Amestecarea secvențială a bazelor de date devine o regulă obișnuită: pune o condiție pe baza de date a înregistrării, dă-i un punctaj mai mare, iar pâlnia servește acea bază de date cât timp oricare dintre înregistrările ei așteaptă.

Înregistrările de campanie sosesc într-o actualizare minoră a versiunii 2026.2, la scurt timp după lansarea principală.

Guvernanță

Fiecare decizie este consemnată

Pe un motor de dirijare care nu se poate explica pe sine nu îl poți susține în fața unui client, a unui auditor sau a propriei echipe. Raportarea Priority Flows are nevoie de un Priority Flow; evidența deciziilor și punctajul live din Timp real se aplică oriunde este activată distribuția.

Evidența completă a deciziilor

Fiecare interacțiune vine cu un jurnal de proces – evidența a tot ce i s-a întâmplat: Priority Flow-ul în care a intrat și punctajul de pornire, fiecare regulă care s-a potrivit și cât a adăugat, creșterile SLA, excepția care i-a fixat destinația, suprascrierile manuale împreună cu autorul lor și expirările.

Urmărește clasamentul în direct

Timp real capătă punctajul curent, etapa SLA – în SLA, apropiere de SLA cu treapta și ritmul aflate în vigoare sau după termenul limită – și întreruperile, adică munca live pe care matricea a lăsat-o să ajungă la un agent deja ocupat.

Suprascrie o prioritate manual

Tastează un punctaj nou direct în celula de prioritate din Timp real. Elementul este marcat ca setat manual, creșterea în timp continuă să se aplice peste el, iar suprascrierea este scrisă în evidență împreună cu persoana care a făcut-o.

Raportarea Priority Flows

Câtă muncă a trecut prin Priority Flows, cât a așteptat, cât din ea și-a atins SLA și ce punctaj avea un element când a ajuns la un agent – cu o defalcare pe canale, cât din munca dislocată de o întrerupere a fost reluată și un tabel din care poți coborî până la orice interacțiune.

De ce a fost ocolit un agent

Când rotația canalelor îndepărtează munca de cineva, motivul este consemnat – de exemplu, două apeluri la rând.

Privind înainte

De ce contează dincolo de dirijare

Dirijarea inteligentă a muncii are nevoie de două lucruri pe care produsul nu le avea: o singură scară pe care poate fi comparată orice unitate de muncă și o evidență completă a motivelor din spatele fiecărei decizii. 2026.2 le construiește pe amândouă. În această versiune nu există funcționalități de dirijare cu AI – dar acesta este stratul de care ele ar avea nevoie și este acum la locul lui.

Administrare

Un singur profil în locul Drepturilor și Accesărilor

Permisiunile stăteau până acum în două obiecte care trebuiau întreținute separat și legate pentru fiecare utilizator. Acum sunt un singur Profil – ce poate face cineva, ce poate administra, la ce cozi, categorii și baze de date se aplică acest lucru și cum se comportă persoana respectivă în centrul de contact, în nouăsprezece arii.

Reproiectat

Profilurile

Un profil se deschide pe patru file: Acces și domeniu de aplicare, Matrice de distribuție, Rotație canale și Membri și suprascrieri. Fiecare arie arată ce poate face un utilizator, ce poate administra și la ce cozi, categorii, baze de date sau comenzi macro anume se aplică acest lucru – cu un indicator live pe fiecare arie care are ceva activat.

Câteva lucruri s-au mutat acolo unde le caută oamenii: traducerile personalizate stau acum sub Workflows, vechiul drept GDPR este acum Anonimizare într-o nouă arie Date și confidențialitate, iar arii noi acoperă Gestionare activități, Spațiu de lucru, Funcții AI, Dispozitive și Gestionare utilizatori.

Funcționalitate nouă

Împrumută agenților un al doilea profil

Fiecare utilizator are un profil principal și poate avea alte profiluri atașate peste acesta. Atașarea unuia doar adaugă acces – nu poate lua niciodată nimic din profilul principal – așa că, dacă vrei să muți câțiva dintre agenții tăi VIP pe cozile obișnuite pentru o după-amiază aglomerată, nu mai trebuie să construiești un grup de drepturi de unică folosință și să îl desfaci după aceea.

Atașează din detaliul utilizatorului, din fila Membri a profilului sau direct din Timp real › Utilizatori, în timp ce urmărești cozile – un singur agent sau o selecție întreagă deodată. Fila Membri a profilului listează toți utilizatorii la care este atașat, iar în detaliul unui utilizator apar toate profilurile atașate lui, împreună cu persoana care le-a atașat.

Atașările limitate în timp – să planifici când începe și când se încheie o atașare, iar apoi să revină de la sine – urmează într-o actualizare minoră a versiunii 2026.2. În lansarea inițială, un profil atașat rămâne până când cineva îl elimină.

Funcționalitate nouă

Număr maxim de tichete

O limită per agent pentru tichetele deschise, alături de limitele existente pentru activități și pentru înregistrările de campanie de ieșire. Se aplică în momentul în care un tichet ar urma să fie asignat, așa că o coadă de tichete nu împinge niciodată un agent peste limita lui.

Îmbunătățit

Setează dintr-o dată modul de conectare pentru toate cozile

Ecranul de profil în care acorzi cozile capătă un control în masă pentru modul în care agenții se conectează la ele: se aplică pe întreaga listă de cozi, nu doar pe pagina afișată, și atinge doar cozile pe care profilul le poate vedea. Pentru că un agent poate avea o singură conectare activă la o coadă de ieșire, o modificare în masă care ar lăsa două cozi de ieșire conectate se oprește și întreabă care dintre ele o păstrează.

Spațiul de lucru al agentului

Activitățile de apel și de chat, reproiectate

Activitățile au fost preluate unu la unu când Daktela a trecut pe Neo și nu mai corespundeau cu reproiectarea tichetelor, livrată în 2026.1. Activitățile de intrare, de ieșire, de campanie și de chat sunt reconstruite pentru a sta cum trebuie lângă noile detalii de tichet – aceleași capabilități, așezate din nou, cu excepția celor două widgeturi menționate mai jos.

Ce vor vedea agenții tăi și cum să îi pregătești

Aceasta este singura schimbare pe care o întâlnește fiecare agent la prima conectare, așa că merită câteva minute la o scurtă ședință de echipă.

Panoul de apel sau de chat își păstrează locul – Panoul de apel în dreapta, conversația Chat web în stânga – iar tot ce stătea în jurul lui într-un aranjament personalizat este acum o filă alăturată: Contact și Cont, Activități, Asignare tichet și așa mai departe. O filă se deschide prima, iar un administrator alege care. Două widgeturi sunt retrase: Ticket – Doar citire, care făcea aceeași treabă ca Asignare tichet, și Calendar, care se poate deschide chiar din ecranul activității. Dacă vreuna dintre cozile tale folosea unul dintre ele, spune-i echipei respective unde să caute de acum.

Funcționalitate nouă

Lucrează mai departe fără să pierzi o conversație

Navighează în altă parte în timpul unui apel live și un widget flotant te urmează prin aplicație: cronometrul, direcția și coada, cu cine vorbești, aceleași comenzi de apel și Închidere apel.

Mesajele funcționează invers. Când unul sosește pe o conversație pe care nu o ai în față, un panou flotant îl afișează – numărul de mesaje necitite, de cât timp așteaptă, o previzualizare a ceea ce s-a spus și un buton care duce direct înapoi în chat. Acoperă fiecare canal de mesagerie, nu doar chatul web, și poate fi dezactivat pe fiecare coadă în parte.

Reproiectat

Setările widgeturilor, editate chiar în activitate

Constructorul pentru fiecare coadă nu mai este o pânză abstractă de blocuri și lățimi. Arată exact ca ecranul real al activității și se editează pe loc: trage de bara de file ca să le reordonezi, marchează cu o stea fila care se deschide prima, elimină o filă sau adaugă un widget nefolosit și deschide setările proprii ale oricărui widget din rotița lui. Filele se previzualizează cu conținut real, din cea mai recentă activitate la care coada a răspuns.

Pe cozile de campanie, formularul înregistrării este plasat din start și nu poate fi eliminat.

Funcționalitate nouă

Contactul și contul pe o singură filă

Widgeturile separate Contact și Cont fuzionează. Când nu este legat nimeni, fila se numește „Asignare contact” și afișează o grilă în care se poate căuta; când un contact este legat, afișează detaliile contactului și, sub ele, contul acestuia. Administratorii aleg ce câmpuri personalizate apar, pentru fiecare entitate.

Poți crea contacte și conturi noi fără să părăsești apelul – adaugi un contact din antetul grilei sau creezi un cont direct din câmpul de cont al contactului. Modificările nesalvate transformă Închidere în Salvare și închidere, așa că nimic nu se pierde în tăcere.

Îmbunătățit

Aceleași widgeturi pe fiecare canal de chat

Canalele de chat cărora le lipseau widgeturi pe care apelurile le aveau deja – utilizatori în timp real, bază de cunoștințe – oferă acum setul complet. Paleta este identică pentru apeluri și chaturi, cu formularul înregistrării ca singură excepție rezervată apelurilor.

Ce rămâne la fel

Nimic din toate acestea nu ți se întâmplă din greșeală

Dacă nu schimbi nimic, nu se schimbă nimic.

Agenții aleg în continuare tichete din vizualizările de tichete și le sortează după termenul limită SLA. Tichetele sunt împinse către oameni abia după ce creezi o coadă de tichete sau o regulă de distribuție – nu înainte.

Cozile de e-mail rămân neschimbate.

Configurarea căsuțelor poștale și a dirijării e-mailurilor rămâne exact ca astăzi. Noul strat de reguli se așază deasupra: dirijarea e-mailurilor se aplică prima, regulile decid după aceea, iar un tichet care nu se potrivește cu nicio regulă este tratat manual, exact ca acum.

Ce se schimbă pentru toată lumea

Ce se întâmplă de la sine la actualizare

Tot restul rămâne la alegerea ta. Aceasta este lista completă a ce vine de la sine.

Drepturile și Accesările devin Profiluri

Obiectul Drepturi al fiecărui utilizator devine profilul său principal; obiectul Accesări devine un profil atașat peste acesta. Accesul efectiv după actualizare corespunde celui de dinainte – aceiași oameni, aceleași permisiuni, un singur obiect de întreținut în locul a două obiecte legate.

Prioritatea unui agent pe o coadă se numește acum Rang

Numărul care decide ce agenți sunt încercați primii – setat pentru fiecare coadă în profilul lor – se numește acum Rang, ca să nu mai fie confundat cu prioritatea purtată de munca în sine. Acum are valori de la 0 la 10, cu 10 ca maxim, iar valorile existente sunt convertite în timpul migrării. Numărul pe care îl citești se schimbă; ordinea în care li se oferă muncă agenților nu.

Aspectul dashboardului și scurtăturile de tastatură se mută

Ele vin acum din primul profil atașat unui utilizator – adică exact ceea ce devine vechiul lui obiect Accesări.

Activitățile de apel și de chat sunt așezate din nou

Fiecare agent care preia apeluri sau chaturi întâlnește noul aspect la prima conectare. Capabilitățile sunt aceleași, cu două widgeturi retrase pentru că altceva le face deja treaba. Ce vor observa este descris mai sus.

Matricea de distribuție arată diferit

Câte un card pentru fiecare canal de intrare în locul unei grile, citit în numere întregi: „Maximum 3 deodată” înseamnă trei. Câtă muncă ajunge la un agent nu se schimbă deloc.

Prioritatea cozii devine un număr liber

Pe orice tip de coadă, în același spațiu numeric ca punctajele din Priority Flows, în locul nivelurilor de la 0 la 10 pe care le setai înainte. Se aplică muncii care sosește direct la o coadă; munca sosită dintr-un Priority Flow își păstrează punctajul câștigat.

Alte îmbunătățiri

Și multe altele

Alte modificări în distribuție, tichete și administrare.

Distribuție și cozi

Un tichet în așteptare nu se pierde niciodată

Setează un timp maxim de așteptare și ce se întâmplă după el: depășire către o altă coadă de tichete, intrare într-un Priority Flow cu o creștere opțională de escaladare, actualizarea tichetului și eliberarea lui spre tratare manuală sau, pur și simplu, încheierea activității de distribuție, în timp ce tichetul rămâne pe loc.

Actualizări precise de câmp la expirare

Fiecare câmp dintr-o actualizare la expirare își alege propriul mod: setează o valoare, înlocuiește ce conține deja un câmp cu valori multiple sau îl golește. Câmpurile obligatorii nu pot fi golite.

Depășirea se setează pe coadă

Unde ajunge munca dacă așteaptă prea mult se setează chiar pe coadă, în loc să fie repetat în fiecare Priority Flow care trimite către ea.

Un Priority Flow nu poate fi salvat pe jumătate configurat

Fiecare fel de muncă dirijată într-un Priority Flow trebuie să aibă unde să meargă, iar nimic nu poate începe să îi trimită un fel nou de muncă până când golul nu este acoperit.

Export și import Priority Flows

Mută un Priority Flow configurat între medii, în loc să îl reconstruiești manual.

Tichete

Acceptarea unui tichet este silențioasă

Preluarea unui tichet distribuit îl trece în starea Deschis și ți-l asignează printr-o singură actualizare, care nu trimite notificări și nu declanșează niciuna dintre automatizările pe evenimente – iar vizualizarea ta îl arată imediat, fără a reîncărca pagina.

Eligibilitate mai largă pentru distribuție

Un tichet care este deja deschis sau care are deja un proprietar poate fi totuși preluat de o regulă. Un tichet iese din calcul dintr-un singur motiv: se află deja într-o coadă de tichete.

Un constructor de reguli mai ordonat

Ca să construiești condițiile unei reguli de distribuție, alegi dintr-o listă lungă de câmpuri de tichet. Lista este acum grupată în ce tocmai s-a întâmplat, câmpurile proprii ale tichetului și câmpurile tale personalizate – și nimic nu se deschide gol: fiecare listă derulantă pornește de la o valoare reală, iar unitățile de timp pornesc de la minute.

Timpul în orice valoare de câmp

Escaladează în funcție de cât timp a trecut de când a fost setat orice câmp de dată de pe tichet, de sistem sau personalizat – nu doar pe baza unei liste fixe de stări.

Tranziții reale de stare

O condiție de tranziție se potrivește cu o trecere reală de la o etapă sau stare la alta și nu se mai declanșează la actualizări în care valoarea a rămas pur și simplu aceeași.

Administrare și securitate

Împrumut planificat de profil În curând

Un profil atașat va putea purta propria dată de început și de sfârșit, care se încheie întotdeauna la miezul nopții, ca nimeni să nu piardă accesul în mijlocul schimbului. Planifică unul din timp și apare ca programat până când se activează. Sosește într-o actualizare minoră a versiunii 2026.2.

Ieșire curată la eliminarea unui profil În curând

Când un profil atașat dispare, utilizatorul pierde doar cozile pe care i le acorda numai acesta: activitățile lui deschise din acele cozi sunt închise și este deconectat exact de la ele. Cozile acordate din altă parte rămân neatinse. Se livrează împreună cu împrumutul planificat.

Șefi de echipă fără drepturi complete de administrare

Un profil poate fi limitat la utilizatorii pe care îi poate gestiona – pe echipe sau individual – și la celelalte profiluri pe care le poate edita.

Câștigă varianta cea mai favorabilă

Acolo unde un profil principal și unul atașat se suprapun, se aplică setarea mai permisivă: rangul mai mare, setul mai larg de acțiuni și modul de conectare care păstrează agentul disponibil în mai multe cozi. Două setări care nu pot fi îmbinate – conectarea unică la o coadă de ieșire și matricea de distribuție – urmează profilul principal.

Raportare eroare are nevoie de Resurse

Resurse, Raportare eroare și Solicitare funcționalitate stau împreună sub ce poate face un utilizator, iar ultimele două nu pot fi acordate fără prima.