Chi può approvare e come lo sa il portale
Il portale sa chi può approvare perché ogni accesso ha cinque switch: visualizzazione, commento, approvazione, caricamento e download. Un nuovo accesso è di sola visualizzazione; solo un accesso con l'approvazione abilitata raggiunge la rotta decisionale, e la pagina non mostra mai un pulsante che l'accesso non può utilizzare. Un accesso è limitato a un singolo progetto o a un intero cliente, e identifica una persona specifica quando lo studio inserisce la sua email o il suo telefono. Ogni decisione viene registrata insieme all'accesso e alla sessione da cui proviene.
Cinque switch su ogni accesso
Un accesso al portale ha cinque valori booleani: visualizzazione, commento, approvazione, caricamento e download. Lo studio li imposta quando crea l'accesso, e un accesso richiesto senza permessi è di sola visualizzazione. Ogni rotta del portale dichiara il singolo permesso di cui ha bisogno e un wrapper controlla l'accesso prima che la rotta venga eseguita, così la rotta non deve mai ricordarsi di effettuare il controllo.
L'approvazione è lo switch fondamentale per l'approvazione finale. La rotta decisionale lo richiede; un accesso di sola visualizzazione o di solo commento non può affatto raggiungere la rotta, e la risposta è lo stesso rifiuto che riceverebbe un estraneo. La pagina del portale legge i permessi dell'accesso quando si apre e nasconde ciò che l'accesso non può fare, così un cliente con un accesso di solo commento vede la discussione ma non il pulsante di approvazione, anziché vedere un pulsante che poi dà errore.
La visualizzazione non è volutamente implicita negli altri permessi. Un accesso che può approvare ma non visualizzare è un errore che uno studio può commettere tramite l'API, e il prodotto fa sì che la rotta di visualizzazione dia un rifiuto in modo che lo studio se ne accorga, anziché correggere l'errore in silenzio.
Un accesso di progetto o un accesso di cliente
Un accesso è associato a un singolo progetto o a un singolo cliente. Un accesso di progetto vede quel progetto e nient'altro. Un accesso di cliente vede ogni progetto di quel cliente. Un accesso non associato a nessuno dei due non vede nulla, quindi non può decidere nulla. Per stabilire se una determinata approvazione spetti a questo accesso, basta leggere la stessa regola al contrario: l'approvazione si trova su un task, il task su un progetto, e l'accesso deve essere limitato a quel progetto o al cliente di quel progetto.
Il progetto e il cliente a cui punta un accesso vengono verificati rispetto all'organizzazione dello studio prima che l'accesso venga registrato, in modo che un accesso non possa mai puntare a organizzazioni diverse; inoltre, un progetto o un cliente mancante restituisce un errore di non trovato, anziché creare un accesso con un riferimento interrotto.
Il job di sollecito utilizza la stessa regola di ambito per decidere quali accessi sollecitare quando un'approvazione supera il suo SLA, in modo che l'accesso che riceve il sollecito sia sempre un accesso abilitato ad agire.
Un accesso per persona
Un accesso ha un'etichetta scelta dallo studio, come il nome del cliente o di una persona specifica presso il cliente. Quando lo studio crea un accesso per un cliente senza specificare altro, l'invito viene inviato all'email e al telefono di contatto del cliente stesso. Quando l'accesso è destinato a una sola persona - il responsabile marketing anziché l'indirizzo di fatturazione - lo studio inserisce l'email o il telefono di quella persona, e l'invito viene inviato lì.
Per un legame più stretto tra l'accesso e la persona, un accesso può richiedere un codice monouso via SMS o email in aggiunta al link: sei cifre, cinque minuti, cinque tentativi e un nuovo invio consentito dopo un minuto. Un accesso può anche limitare il numero di dispositivi, da uno a venti. Con un limite pari a uno, l'accesso da un dispositivo esterno trasferisce la sessione su quest'ultimo e termina immediatamente tutte le altre; con un limite superiore, termina solo la sessione più vecchia. Lo stesso dispositivo non viene mai disconnesso: un aggiornamento della pagina o un cookie perso non sono una punizione.
La traccia dello studio mostra, per ogni accesso, quanti dispositivi diversi lo hanno utilizzato. Un accesso destinato a una sola persona che mostra sei dispositivi indica che il link è stato condiviso, e lo studio può revocarlo e crearne uno nuovo nello stesso minuto.
Quando lo studio decide per conto del cliente
Anche un producer può registrare una decisione lato studio, avendo ottenuto il via libera del cliente. La riga della decisione riporterà quindi l'ID utente del producer e un tipo di attore pari a 'user'. Una decisione proveniente dal portale riporta invece un tipo di attore pari a 'portal' e nessun ID utente. Le due cose sono distinguibili per sempre nel feed e nel registro di controllo, quindi 'il cliente ha approvato' e 'abbiamo approvato per conto del cliente' non saranno mai la stessa riga.
I sign-off interni - una fase di approvazione superata da un producer o da un regista - utilizzano lo stesso meccanismo, con un membro dello studio come approvatore e gli assegnatari del task come destinatari dei solleciti quando l'attesa si protrae troppo a lungo.
Scadenza, revoca e cosa vede lo studio
Di default, un accesso scade dopo 30 giorni. Lo studio può impostare da 1 a 365 giorni, o scegliere esplicitamente nessuna scadenza; l'omissione di questo valore evita di lasciare aperto per errore un accesso permanente. Un accesso revocato viene rifiutato immediatamente. Nella lista dello studio, un accesso revocato viene mostrato come revocato anziché scaduto, perché uno studio che ha disattivato un link vuole avere la certezza visiva di averlo fatto.
Il lato studio elenca ogni accesso con la relativa etichetta, lo stato, i permessi, la prima apertura, l'ultimo rilevamento, i dispositivi distinti e il numero di approvazioni del cliente registrate. Prima che esistesse questo elenco, l'unica risposta sincera a 'lo avrà aperto?' era una telefonata.
La creazione e la revoca di un accesso vengono verificate nel registro, includendo le impostazioni dell'accesso e mai le sue credenziali. Anche un accesso negato viene registrato, indicando il motivo - non trovato, revocato, scaduto o codice monouso richiesto - visibile solo allo studio e mai mostrato alla persona che tenta l'accesso, poiché una differenza nelle risposte di rifiuto funge da oracolo per chi tenta di indovinare.
- Accesso predefinito: sola visualizzazione, 30 giorni, invito inviato ai recapiti del cliente.
- L'approvazione richiede lo switch di approvazione; l'interfaccia utente nasconde ciò che l'accesso non può fare.
- L'ambito è limitato a un singolo progetto o a un singolo cliente; mai tra organizzazioni diverse.
Domande frequenti
- Due persone presso lo stesso cliente possono avere diritti diversi?
- Sì. Crea un accesso per ciascuna persona, ognuno con la propria email o telefono e i propri switch. Un accesso può essere di solo commento e l'altro di approvazione, e il registro indicherà quale accesso ha preso la decisione.
- Cosa vede un cliente con un accesso di sola visualizzazione?
- L'elemento e il suo stato, oltre alla discussione se i commenti sono abilitati. Nessun pulsante di approvazione, nessuna area di caricamento, nessun link di download. La pagina offre solo ciò che l'accesso consente di fare.
- Un cliente può vedere altri progetti?
- Un accesso di progetto vede un singolo progetto. Un accesso di cliente vede i progetti di quel cliente. Nessun accesso può vedere altri clienti, l'elenco dei clienti dello studio o i nomi del personale non coinvolto.
- Come fa lo studio a sapere se un link viene condiviso?
- La traccia mostra i dispositivi distinti per ciascun accesso. Un accesso destinato a una sola persona che mostra molti dispositivi è il segnale d'allarme; lo studio può quindi revocarlo e crearne uno nuovo immediatamente.
- Una decisione inserita dallo studio per conto di un cliente viene contrassegnata in modo diverso?
- Sì. Una decisione del portale contiene il tipo di attore del portale e nessun utente; una decisione dello studio contiene l'ID utente del producer. Il feed e il log le tengono separate.