Ruoli e autorizzazioni — ruoli di sistema e di tenant costruiti a partire da concessioni di autorizzazioni con ambito definito
Last updated: August 09, 2026 by Steve
Ruoli e autorizzazioni
AccessPoint utilizza autorizzazioni granulari, configurabili per tenant, anziché mansioni fisse. In questa pagina si costruiscono i ruoli utilizzati dal proprio ufficio — Coordinator, Reviewer e così via — concedendo singole autorizzazioni da un catalogo suddiviso per categorie. Questa pagina definisce cosa può fare ciascun ruolo; l'assegnazione dei ruoli alle persone avviene in Gestione utenti.
Dove trovarlo
Aprire Impostazioni dalla barra degli strumenti dell'app e scegliere Ruoli e autorizzazioni nel gruppo Utenti e accesso.
Ruoli di sistema e ruoli di tenant
- Administrator è l'unico ruolo di sistema predefinito.
- Ogni altro ruolo — tutti i ruoli di tipo coordinatore — è definito dall'utente. In genere vengono precompilati a partire da un Pacchetto giurisdizionale e personalizzati in seguito.
I ruoli sono inoltre di due tipi, e la differenza determina dove vengono concessi:
- Ruoli assegnati — Administrator e i ruoli propri del tenant. Un amministratore li concede in Gestione utenti, facoltativamente con una data di scadenza, utile per collaboratori esterni e utenti dei clienti.
- Ruoli di relazione — Custodian, Contributor, Reviewer, Advisor e Reader. Vengono conferiti automaticamente quando qualcuno viene aggiunto a un incarico, a un'attività, a una revisione o a un caso. Non possono essere assegnati in Gestione utenti.
La maggior parte degli uffici lavora con ruoli corrispondenti a questi archetipi:
| Ruolo | Tipo | Cosa si fa |
|---|---|---|
| Request Coordinator | Assegnato | Gestire l'intero ciclo di vita delle richieste di accesso — creare richieste, assegnare il lavoro, revisionare le consegne e inviare le risposte. |
| Custodian | Di relazione | Raccogliere e inviare documenti per incarichi specifici. |
| Contributor | Di relazione | Completare attività specifiche all'interno di un incarico. |
| Reviewer | Di relazione | Revisionare il lavoro completato e approvarlo o richiedere modifiche prima dell'invio della risposta. |
| Advisor | Di relazione | Fornire consulenza su un caso — accesso in sola lettura più la possibilità di visualizzare e segnalare le redazioni per la discussione. |
| Reader | Di relazione | Visualizzare in sola lettura i dettagli di un record a cui si è stati aggiunti. |
| Administrator | Assegnato (predefinito) | Configurare il sistema — gestire gli utenti, impostare i tipi di richiesta, definire i flussi di lavoro e mantenere le impostazioni di sistema. |
I nomi dei ruoli assegnati nel proprio tenant possono differire dagli archetipi sopra riportati, ma il comportamento delle autorizzazioni è lo stesso.
Nota sulla privacy: i ruoli Custodian, Contributor, Advisor e Reader lavorano su contenuti anonimizzati. Il firewall PII rimuove le informazioni personali del richiedente prima che il contenuto arrivi a loro.
Costruire un ruolo
| Elemento | Dettagli |
|---|---|
| Nome e descrizione | Entrambi sono traducibili, in modo che il ruolo venga visualizzato correttamente in ciascuna delle lingue attive del tenant. |
| Concessioni di autorizzazioni | Concedere singole autorizzazioni da un catalogo di autorizzazioni suddiviso per categorie. |
| Ambito | Ogni concessione può essere Globale oppure avere un ambito definito. |
Ruoli abbinati ai casi (dinamici)
Un ruolo può anche essere creato come abbinato ai casi: le sue autorizzazioni si applicano solo ai casi che corrispondono a una regola definita dall'utente. Una regola può basarsi su:
- il valore di un campo personalizzato a selezione singola — «Il cliente è Acme»;
- un tipo di caso;
- una fase del ciclo di vita — «tutte le richieste chiuse».
I casi corrispondenti compaiono nelle dashboard del membro e si aprono secondo le autorizzazioni concesse dal ruolo; tutto il resto rimane invisibile. Prima del salvataggio, l'editor mostra un conteggio in tempo reale — «attualmente corrisponde a N casi» — così da vedere la portata di una regola mentre la si scrive.
Le regole aggiungono soltanto accesso — non lo rimuovono mai. Una regola abbinata ai casi non può togliere a un membro un accesso che già possiede tramite un altro ruolo. Verificare gli altri ruoli di un membro prima di dare per scontato che sia la regola a limitarlo.
Usi tipici:
- Un fornitore di servizi che dà a ciascuna organizzazione cliente accesso esattamente ai propri casi.
- Personale junior che modifica i propri casi ma può leggere l'intero corpus chiuso come riferimento.
- Un team a cui viene concesso l'accesso a un solo tipo di caso.
Se i membri abbinati ai casi sono utenti guest, ricordare che un guest non dovrebbe mai detenere anche un ruolo permanente con visibilità globale. La regola delimita ciò che AccessPoint mostra loro — non ciò che mostrerebbe una concessione separata attribuita con leggerezza.
Reportistica per i membri abbinati ai casi
Concedere l'autorizzazione Creare report sui casi corrispondenti e il membro ottiene il generatore di report, i report salvati e Ask AccessPoint soltanto sui casi che corrispondono alla sua regola — comprese le esportazioni e i riquadri fissati. I campi con le PII del richiedente non vengono mai proposti e il membro vede solo i propri report salvati, non quelli condivisi dal team.
Due elementi restano a livello di tenant e pertanto non sono disponibili: le sezioni di report predefinite nel pannello Report, che riportano cifre fisse a livello di intera organizzazione, e My Day con le notifiche.
Qui l'avvertenza sulla cumulabilità vale in modo particolarmente netto. Se la stessa persona detiene anche un'ordinaria autorizzazione di reportistica tramite un altro ruolo, quella non è vincolata alla regola e vedrà le cifre dell'intera organizzazione.
Dirigente responsabile (titolare responsabile)
Ogni caso può designare un dirigente responsabile — la persona che risponde delle decisioni assunte sul caso, distinta dal coordinatore che svolge il lavoro.
Designare qualcuno gli dà accesso solo a quel caso. Può leggerlo, vedere il richiedente, aprire i documenti e agire sulle revisioni, ma non può modificarlo né eliminarlo. È una scelta deliberata: consente di rendere qualcuno responsabile di un singolo caso — anche un consulente esterno che è guest nel proprio tenant — senza concedere un ruolo che gli mostrerebbe tutto.
I casi di cui è responsabile che vanno in ritardo compaiono nel suo My Day, così la vigilanza non dipende dal fatto che qualcuno si ricordi di avvisarlo.
Chi può essere designato è determinato dall'autorizzazione Agire come dirigente responsabile, che di per sé non concede accesso a nulla.
Le autorizzazioni nella pratica
Le autorizzazioni determinano cosa gli utenti possono vedere e fare in tutto il prodotto. Alcuni esempi che ricorrono altrove in questa documentazione:
- Visualizzare le PII del richiedente — nome, e-mail e altre informazioni personali del richiedente sono visibili solo ai ruoli dotati di questa autorizzazione; i ruoli Custodian e Contributor lavorano invece a partire da istruzioni anonimizzate, senza disporne.
- Agire come dirigente responsabile — determina chi può essere designato titolare responsabile di un caso. Di per sé non concede accesso a nulla.
- Creare report sui casi corrispondenti — dà ai membri di un ruolo abbinato ai casi la reportistica sui soli casi corrispondenti.
- RequestorManage — necessaria per modificare i contatti e le istituzioni dei richiedenti.
- ConfigurationManage — consente a un utente di condividere le viste salvate a livello di tenant e di gestire le viste condivise.
- Autorizzazioni
*.configure— alcuni gruppi di Impostazioni (flussi di lavoro di revisione, configurazione di incidenti/valutazioni/reclami relativi alla privacy) compaiono solo se si dispone della relativa autorizzazione di configurazione.
Ruoli e assegnazione agli utenti
I ruoli non hanno alcun effetto finché non vengono assegnati. Utilizzare Gestione utenti per assegnare o rimuovere ruoli per ciascun utente. Un utente può avere più di un ruolo — le autorizzazioni sono cumulative — e una protezione dell'ultimo amministratore impedisce di rimuovere l'ultimo amministratore, così da evitare di restare esclusi dal sistema.