Data ultimo aggiornamento: 14/08/2023

Gestione degli accessi/sicurezza

Quando si introduce il modulo CRM in azienda, si pone quasi sempre un problema di sicurezza nell'accesso ai dati amministrativi/gestionali, cioè il dare accessibilità a certi dati a determinate persone (come in particolare gli agenti) che solitamente non utilizzano i programmi gestionali. La riservatezza vuole inoltre ed infatti che un agente non debba vedere chi sono i clienti di un altro agente (o i dati dei clienti, o tutti i clienti dell'azienda), visto che tali dati costituiscono solitamente un patrimonio aziendale significativo. La struttura della funzione commerciale in una azienda può inoltre prevedere che vi siano direzioni commerciali distinte in base al mercato (per esempio vendite dirette, vendite indirette) o in base alla linea di prodotto-servizio, che vi siano gerarchie tra le persone che compongono la struttura commerciale, e/oppure vi siano responsabili 'trasversali' nell'ambito della struttura gerarchica.

Inoltre naturalmente, non si vuole che un agente (o altri del settore commerciale) possa procedere ad una stampa di un bilancio, o a visualizzare o modificare una distinta base, ecc... Si vuole però (ed è auspicabile) che possa vedere lo scadenzario dei propri clienti, o lo storico ordini dei propri clienti, e così via.

Per poter raggiungere questi obiettivi occorre utilizzare le funzioni di sicurezza standard di Business, in particolare:

• la codifica di ruoli ed utenti (rispettivamenti ruoli e operatori negli archivi procedura
• la definizione di accessi ai singoli programmi ai singoli utenti o ruoli (per esempio non voglio che i miei agenti possano eseguire il programma 'Stampa Bilancio contabile')
• la configurazione delle maschere (eseguito da un amministratore) quando si vuole un accesso parziale alle funzioni di un determinato programma (per esempio voglio che un utente di Business possa aprire un impegno cliente di un suo cliente ma non possa modificarlo o cancellarlo)

Tuttavia con le funzionalità sopra non è possibile discriminare, all'interno di una stesso archivio (per esempio dei clienti, o dei leads) l'accesso in modo distinto a determinati records (o istanze) dei dati ivi contenuti (cioè non è possibile definire che l'utente Paolo, che è l'agente Rossi Paolo, possa accedere dal programma 'Anagrafica Clienti' solo ai suoi clienti, e non agli altri).

Allo scopo si consentire quindi una gestione più spinta in tal senso, è necessario introdurre (e gestire) altre informazioni. Innanzitutto è bene distinguere:

• operatore (o utente) di Business: sono persone che utilizzano la procedura Business; può essere che certi agenti siano utenti di Business ed altri no, che ci siano utenti di Business che devono gestire dati di altri o per conto di altri (per esempio la segretaria del responsabile vendite, o il responsabile del marketing). Comunque è consigliabile che tutti i gestori di informazioni CRM (per esempio tutti i commerciali/agenti) siano codificati come operatori, anche se non dovessero utilizzare Business direttamente. Gli operatori sono identificati da una 'stringa' alfanumerica di massimo 20 caratteri, che viene utilizzata per accedere all'applicazione Business
• agente: sono persone che prendono provvigioni sulle vendite; possono essere o meno utenti di Business, come abbiamo detto. Sono identificati dal 'codice agente', un numero compreso tra 1 e 9999
• utente di CRM: sono gli operatori (cioè utenti) di Business che devono utilizzare anche le funzioni del modulo CRM (in particolare della interfaccia unificata per la gestione dei lead/opportunità/attività e del programma 'Gestione offerte' e 'Stampa lead/opportunità/attività'). NB: solo per gli utenti CRM sarà possibile definire delle politiche di sicurezza al fine di discriminare, all'interno di una stesso archivio (per esempio dei clienti, o dei leads) l'accesso in modo distinto a determinati records (o istanze) dei dati ivi contenuti
• persona facente parte dell'organizzazione della ditta: sono tutte le persone che hanno una qualche relazione con la gestione dei dati di Business, che siano o meno operatori, che siano o meno agenti, che siano o meno utenti CRM; vengono (devono essere) codificati nella finestra 'Organizzazione' della ditta. Sono identificati con un numero compreso tra 1 e 999999999

Nella tabella degli operatori di Business c'è una informazione specifica 'Utente CRM' Si/No (con una spunta) che consente di identificare gli operatori che dovranno usare le funzioni specifiche del modulo CRM, da quelli che hanno altre funzioni, per esempio gli amministrativi, gli addetti al magazzino, ecc...

L'associazione tra persone delle organizzazione e operatori e agenti avviene:

• codificando gli operatori nella relativa tabella avendo cura di identificare gli utenti CRM da quelli non CRM
• riempendo opportunamente la finestra dell'organizzazione della ditta si definiscono chi sono le persone che sono anche operatori e con quale nome operatore di ingresso a Business, si crea così un collegamento tra l'operatore e l'identificativo della stessa persona nell'organizzazione di quella ditta, necessario soprattutto, ma non solo, quando sullo stesso database si gestiscono due o più ditte
• nella anagrafica ditta, nella finestra 'accessi per operatore' indicare con gli appositi check box se, per ciascun operatore CRM (e per tutti, obbligatoriamente gli utenti CRM), se quell'operatore su quella ditta ha accesso ai dati in visualizzazione, in visualizzazione e modifica, se ha accesso anche all'archivio dei fornitori, e se si tratta di un agente, qual è il suo codice identificativo agente nella tabella degli agenti

Abbiamo già definito Incaricato (o anche: operatore incaricato) come 'il codice identificativo 'operatore' della persona che è codificata come operatore e contemporaneamente fa parte dell'organizzazione della ditta (e pertanto codificata da anagrafica ditta anche nella griglia dell'organizzazione) che si occupa di una determinata cosa (di seguire un determinato cliente o lead, di una certa trattativa, di una determinata offerta).

Abbiamo detto che ogni lead, ogni opportunità, ogni attività può essere assegnato ad un operatore incaricato. Quindi ognuno di queste entità ha un suo 'proprietario' o 'incaricato'. Non abbiamo il codice incaricato sull'anagrafica dei clienti, ma poiché, in presenza del modulo CRM, ogni cliente è anche un lead, l'informazione che ci serve l' abbiamo indirettamente anche sul cliente.

Un lead o un cliente può essere anche di più operatori incaricati contemporaneamente. E' il caso, per esempio, di una azienda che ha due diverse direzioni commerciali per due linee di prodotto diverse, ognuna i propri agenti. Lo stesso cliente potrebbe acquistare prodotti delle due linee da due agenti diversi che seguono il cliente contemporaneamente.

Ora, per poter definire se un utente (se è un utente CRM, in particolare) può accedere solo ai dati dei suoi clienti (meglio: dei suoi leads) nonchè alle sue opprtunità e attività e offerte, o anche a quelle di altri (ed in che modo, cioè se in sola visione / interrogazione, oppure anche in modifica/cancellazione), è necessario indicare delle politiche di sicurezza relativamente all'organizzazione commerciale della ditta, nonché al singolo lead.

Ci sono 3 diverse impostazioni (le principali) necessarie per fare questo:

• in anagrafica ditta, per ogni utente CRM nella funzione-finestra 'accessi per operatore' indicare se per quella ditta quell'operatore può solo vedere i dati CRM, oppure anche modificarli
• nel programma è necessario indicare, per ogni utente CRM, nella tabella 'Accessi CRM per operatore' (BNCRACCC), il tipo di accesso consentito per se e per ogni altro operatore (dell'organizzazione aziendale, su quella ditta) sui dati CRM. Questa tabella permette di definire le regole di accesso (sola lettura, lettura e scrittura, nessun accesso) alle informazioni tra i vari operatori dell'area commerciale, in strutture gerarchiche e non (per esempio reticolari, o matriciali). Tra i vari soggetti nei loro ruoli: per esempio direzione vendite, direzione vendite dirette, direzione vendite indirette, direzione marketing, capi-area, responsabili di prodotto, singoli agenti, operatori del marketing, ecc...
• nel programma 'Gestione Leads/Attività/Opportunità', per ogni lead è possibile associare uno o più operatori incaricati. Ogni lead deve avere almeno un operatore incaricato associato. Tipicamente il commerciale/agente che lo segue. Ma possono essere anche due o più di due (per esempio due linee di prodotto, due direzioni vendite, due diversi agenti/commerciali che interfacciano il cliente)

Si può pertanto così stabilire per per esempio che l'utente roby può accedere in modifica/annullamento solo sui suoi dati (ed i dati dei suoi clienti) e può vedere/interrogare i suoi dati e i dati collegati al suo collega/collaboratore davide. Esempio di impostazione:

Tabella Operatori (OPERAT):

Accessi per operatore sulla ditta PROVACRM (ACCDITO):

Tabella agenti (TABCAGE):

Organizzazione ditta (ORGANIG):

NB: il codice agente indicato sopra nella tabella dell'organizzazione, non è significativo per la gestione dei dati CRM, conta quello indicato in 'Accessi per operatore' sulla ditta.

Accessi CRM per operatore (acccrm):

Nella tabella sopra in sostanza si prevede che, a livello di organizzazione e di sicurezza sui dati, davide sia un agente, che può accedere in modifica e visualizzazione ai soli suoi dati. roby è anche supervisore dell'attività di davide e pertanto oltre ad accedere ai propri dati senza limitazione, può vedere (ma non modificare) i dati dell'operatore davide. rosa è abilitata a modificare e vedere i dati propri (ma rosa per mansioni, di norma, non avrà lead direttamente, in quanto non è un commerciale ma una segreteria commerciale) e i dati sia di davide che di roby. NB: è obbligatorio che ci sia in questa tabella sempre un record che consente all'operatore di gestire i suoi dati: rosa-rosa, davide-davide, roby-roby.

Accessi lead per operatore (gestito in anagrafica lead):

Si noti che il lead 38 è contemporanemante gestito sia dall'operatore roby che dall'operatore davide. Idem il 37 (che è anche il cliente già acquisito 4010038). I lead 41 e 40 invece sono in comproprietà tra roby e rosa. Si tenga presente che rosa potrà accedere anche (indirettamente, per quanto stabilito nella tabella 'Accessi CRM per operatore') a tutti i lead di roby e di davide, sia in modifica che in visualizzazione.

Affinchè un operatore possa accedere ai dati di un lead, occorre che, direttamente o indirettamente (cioè tramite le politiche della tabella di 'Accessi CRM per operatore') egli abbia:

• per la visualizzazione: accessi in visualizzazione a tutti e tre i livelli (ditta, organizzazione e lead) A C E = 'S'
• per la modifica: accessi in modifica a tutti e tre i livelli (ditta, organizzazione e lead) B D F = 'S'

NB: non è permesso, nelle tre tabelle sopra indicate, avere accesso in modifica senza anche avere permesso in visualizzazione!

L'inserimento di un nuovo lead può essere effettuata da ogni utente CRM, assegnandolo a se stesso o ad altri (uno o più operatori) che ne divengono operatori incaricati.

Per l'inserimento di una nuova opportunità (o di una nuova offerte) su un lead, occorre che l'operatore abbia accesso in visualizzazione (direttamente o indirettamente) sui dati del lead relativo alla opportunità o offerta, e che l'operatore che viene assegnato come operatore incaricato dell'opportunità/offerta abbia un accesso in modifica sui dati del lead.

Per la visualizzazione di una opportunità o di un offerta occorre che un operatore abbia accesso sia in visualizzazione che in modifica sul lead relativo alla opportunità/offerta, ed inoltre (se non è direttamente incaricato) che abbia accesso in 'Accessi CRM per operatore' in visualizzazione ai dati dell'operatore che è incaricato dell'opportunità/offerta.

Per la modifica di una opportunità o di un offerta occorre che un operatore abbia accesso in modifica sul lead relativo alla opportunità/offerta, ed inoltre (se non è direttamente incaricato) che abbia accesso in 'Accessi CRM per operatore' in modifica ai dati dell'operatore che è incaricato dell'opportunità/offerta.

Per la cancellazione di lead, opportunità, offerte, si fa riferimento agli accessi per la modifica.

A livello di anagrafica ditta, 'Accessi per operatore', è possibile stabilire un altra indicazione, è quella di dire se l'operatore è autorizzato ad accedere (su quella ditta) all'archivio dei fornitori (e dati correlati come per per esempio ordini fornitori) oppure no. Sarà impostata in un modo (positivo) per l'amministratore del sistema, sarà impostata invece in modo negativo per le persone che non debbono avere accesso a tali informazioni.

Questi meccanismi, uniti alla configurazione delle maschere permette di definire in modo esauriente la maggior parte (ma non tutte quelle possibili) delle casistiche di politiche di sicurezza sui dati.

NB: il test sull'accessibilità da parte dell'utente dei dati a lui riservati, secondo le impostazioni della tabella 'Accessi operatore CRM' viene effettuato solo su una parte dei programmi, non su tutti. Ci sono 4 tipi di programmi in Business, relativamente alla gestione degli accesi CRM:

1. quelli specifici del modulo CRM, in cui le politiche di accesso sopra definite sono pienamente e direttamente supportate:
   • Gestione Leads/opportunità/contatti
   • Gestione offerte
   • Stampa leads/oppurtinità/attività
   • Stampe CRM semplificate
2. i programmi che utilizzano le politiche di accesso CRM tramite i lead (per esempio la gestione dei clienti, in anagrafica clienti, applica le politiche di accesso del lead a cui il cliente è associato nella tabella dei leads):
   • Anagrafica clienti/fornitori ditta
   • Zoom su anagrafiche clienti/fornitori
   • Finestra dei filtri su clienti/fornitori
   • Tab "Offerte", "Documenti", "Ordini" e "Magazzino" della "Desktop consolle" (*)
   • Analisi flusso documentale
   • I campi "Fornitore 1" e "Fornitore 2" ed il pulsante "Codici articolo cliente/fornitore" di anagrafica articolo (*)
   • Le griglie "Listini", "Sconti" e "Provvigioni" nell'anagrafica articoli ed anche in anagrafica agenti (*)
   • Gestione liste selezionate (con alcune specificità)
3. i programmi che gestiscono documenti (visualizzazione/stampa, modifica/inserimento) che sono indirettamente associati ai lead tramite il codice cliente. Parliamo di Impegni, DDT emessi, fatture emesse (documenti di magazzino), e alcune entità del modulo Customer Service. In particolare:
   • Gestione ordini/impegni (BSORGSOR)
   • Stampa Brogliaccio ordini (BSORSTOR)
   • Stampa vis. documenti di magazzino (BSMGSTBO)
   • Stampa vis. schede clienti/fornitori (del magazzino)
   • Stampa/vis. Chiamate/attività/contratti/matricole (customer service)
4. tutti gli altri programmi, che di norma sono utilizzati da persone dell'organizzazione che non fanno parte dei processi commerciali (per esempio funzioni legate alla contabilità, alla logistica, ecc.) Tra cui anche (nota bene): Gestione documenti di magazzino, fatturazione differita, Datawarehouse.

(*): per attivare le limitazioni su questi programmi è necessario attivare esplicitamente l'opzione di registro globale "AbilitaRestrizioniCRM" con valore -1.

NB: alcuni programmi, come stampa schede ordini e stampa schede articoli, stampa partitari, stampa scadenzario, consolle clienti/fornitori/articoli, che in passato, in precedenti versioni del modulo CRM implementavano la politica di accessi allora disponibile, ora non implementano (da Business 2010) più politiche di accessi CRM (pertanto non andrebbero resi disponibili ad utenti CRM che debbano avere restrizioni sui dati). In compenso tali dati, per lo più, nelle nuove versioni CRM, sono direttamente accessibili in visualizzazione da Consolle gestione lead/opportunità/attività.

è bene pertanto, in generale, disattivare l'accesso a tutti gli atri programmi (per esempio da gestione operatori) per quegli utenti che non debbono avere pieno accesso alle informazioni che non siano le proprie (o che non siano la totalità di dati riferibili a tutti i clienti).

Si può tuttavia dare accesso agli utenti CRM anche a programmi che non hanno diretto collegamento con i clienti/leads: per esempio dare accesso al programma stampa situazione ordini, oppure stampa inventario di magazzino (per fornire la disponibilità dei prodotti), anagrafica articoli (attenzione però, in questo caso, ai prezzi e sconti particolari per cliente), gestione documenti di magazzino, ecc... Tenere però presente che in questi programmi non verranno applicati filtri relativi alle restrizioni imposte con le politiche di accesso CRM.

NB: nei programmi di cui al punto c) il 'driver' per l'accessibilità ai dati è sempre il lead (il cliente), cioè posso vedere/stampare oppure modificare/annullare gli ordini dei miei clienti, le anagrafiche dei miei clienti, vedere i documenti emessi nei confronti dei miei clienti, ecc... Nel caso in cui l'operatore CRM sia un agente (nella griglia 'accessi per operatore' della ditta), in questi programmi (BSORSTOR, BSMGSTBO, BSMGSCHC) viene inoltre applicato automaticamente un ulteriore filtro: il codice agente. Cioè nel stampare il brogliaccio ordini, un operatore che è anche un agente, vedrà in stampa solo quelli dei clienti di cui è incaricato, e di cui è anche agente 1 o agente 2 nella testata (per evitare, per esempio, se un cliente è gestito da due persone, agenti, che una delle sue possa vedere gli impegni di competenza dell'altra persona).

Non sono definibili però (e perciò) criteri diversi, per esempio i clienti di una certa categoria o canale, ecc...

NB: nei programmi di cui al punto c), se un operatore (per esempio rosa) ha accesso ad un cliente-lead, che è servito da due agenti (utenti CRM anch'essi), non essendo rosa un agente in quella ditta, avrà visibilità su tutti gli ordini e movimenti di magazzino di quel cliente, indipendentemente che siano relativi al primo o al secondo agente, anche se rosa ha visibilità per organizzazione commerciale ai dati di uno solo de due agenti.

Sintesi delle proprietà di accesso sulle entità gestionali:

• ogni lead può avere 1 (o più) operatori CRM proprietari-incaricati (strutture commerciali con agenti/venditori per linee di prodotti, ecc...) mantenibile da gestione lead
• ogni opportunità, offerta e attività, può avere un proprietario-incaricato
• ogni attività può avere più operatori coinvolti (meeting)

Sintesi dello schema di accessi alle entità gestionali:

• su un lead hanno accesso gli n proprietari/incaricati e chi in 'accessi CRM per operatore' ha visibilità/modificabilità sui dati di uno dei proprietari
• su una opportunità accede l'incaricato-proprietario (unico) e chi in 'accessi CRM per operatore' ha visibilità/modificabilità sui dati del proprietario, e accesso sul lead relativo
• su una offerta accede l'incaricato-proprietario (unico) e chi in 'accessi CRM per operatore' ha visibilità/modificabilità sui dati del proprietario e accesso sul lead relativo
• su una attività accede l'incaricato-proprietario (unico) e chi in 'accessi CRM per operatore' ha visibilità/modificabilità sui dati del proprietario (senza leggere acclead); inoltre, nella rappresentazione 'dove è coinvolto' e nell'agenda, si vedono le attività (compresi i meeting) in cui l'operatore è coinvolto indipendentemente dal legame organizzativo-accessi, o della visibilità sui lead
• su un ordini (BSORGSOR, BSORSTOR), accede chi ha accesso al lead della testata tramite il cliente/destinazione, direttamente come proprietario, o per organizzazione commerciale (acccrm). Se l'operatore è un agente sulla ditta, filtro codice agente su agente 1 e 2
• su un documento di magazzino (BSMGSTBO, BSMGSCHC) accede chi ha accesso al lead della testata tramite il cliente/destinazione, direttamente come proprietario, o per organizzazione commerciale (acccrm). Se l'operatore è un agente sulla ditta, filtro codice agente su agente 1 e 2
• su e-mail accede l'operatore che in organig (per ciascuna ditta) ha l'account nel mittente o destinatario della mail

Assegnazione ad altro utente

E' possibile che un operatore CRM inserisca una entità (per esempio un offerta, una opportunità) e la 'assegni' in proprietà-incarico ad altro utente CRM. per esempio Rosa potrebbe inserire un offerta per Davide o Roby (nell'esempio sopra). Per far si che l'offerta o l'opportunità inserita sia poi 'gestibile' occorre che le relazioni organizzative tra chi inserisce il dato e l'assegnatario siano coerenti. In particolare:

• l'assegnatario è la stessa persona di chi inserisce (ed è la norma)
• l'assegnatario è una persona 'a monte' nell'organizzazione (negli accessi CRM per operatore, tabella 'acccrm'), ed ha accesso in modifica (nonche in visualizzazione) sui dati dell'operatore che inserisce il dato (per esempio davide che inserisce un opportunità assegnandola a Rosa)
• l'assegnatario è una persona 'a valle' nell'organizzazione (negli accessi CRM per operatore, tabella 'acccrm') ed ha accesso in modifica/visualizzazione ai dati del lead a cui l'offerta/opportunità/ecc è relativa (perché deve poi poterla gestire !) per esempio rosa può inserire una offerta e assegnarla in incarico/proprietà a roby, purchè sia un offerta relativa ad un lead su cui roby abbia accesso in visualizzazione/modifica

Aggiungere un nuovo utente CRM ad una installazione di Business

Ogni volta che occorre inserire un nuovo utente delle funzioni CRM, occorre procedere come segue:

1. da 'gestione operatori' (di 'Archivi Procedura'), attribuire un nuovo nome operatore, una password, e contrassegnare l'utente come 'Utente CRM' spuntando l'apposita casella di selezione
2. se il nuovo utente è anche un agente, da gestire nella gestione agenti/provvigioni, creare in anagrafica fornitori l'anagrafica dell'agente, e attribuire un codice agente nella apposita tabella 'Agenti'. Questa operazione, se l'utente è agente su due o più ditte, va fatta per ogni ditta interessata
3. andare in 'Anagrafica Ditta', 'Accessi per operatore' (in ciascuna ditta interessata, se sono presenti due o più ditte) e aggiungere nella apposita finestra, il nuovo operatore, indicando se ha accesso anche alle anagrafiche dei fornitori, e indicando il suo codice agente (se è un agente)
4. sempre in 'anagrafica ditta', nella finestra della funzione 'Organizzazione', aggiungere l'utente con un nuovo identificativo (numerico), inserendo i dati più importanti (per esempio e-mail, nome e cognome, ruolo, ecc.) e facendo particolare attenzione ad inserire nell'apposito campo il nome operatore attribuito al punto 1, e di nuovo, il codice agente relativo (se egli è anche un agente)
5. andare in 'Accessi CRM per operatore' (dal menu: G.C.C) ed inserire almeno una riga con 'Nome Utente' e 'Altro operatore ' impostati entrambi col nome del nuovo operatore CRM, e con 'abilita vis. dati' e 'abilita mod. dati' entrambi spuntati. (questa operazione si può fare più velocemente con il pulsante CTRL+A 'Aggiungi operatori' disponibile in quel programma) Aggiungere inoltre altre righe con 'nome utente' impostato sul nuovo operatore, e con 'altro operatore' impostato su altro nome, per ogni persona (anch'essa utente CRM) i cui dati, in funzione dell'organizzazione commerciale dell'azienda, il nuovo operatore deve poter accedere 'indirettamente' (in visualizzazione o in modifica). Per 'dati' e 'politiche di sicurezza di accesso ai dati', si consulti la parte della guida che parla di 'Gestione Accessi e Sicurezza'
6. avere l'accortezza di utilizzare il nuovo nome operatore CRM nella fase di inserimento o aggiornamento (nella finestra accessi del lead) di ogni anagrafica lead che deve essere 'direttamente' seguita dal nuovo operatore CRM (appena inserito)

Nota per programmatori. Modifiche per migliorie prestazionali, nei controlli degli accessi CRM (gestiti tramite la tabella "temporanea" TTSUBQCRM).

Nei vari programmi che controllano gli accessi CRM fino a Business Cube 2 SR8 si riempiva la tabella TTSUBQCRM con tutti i clienti/fornitori/lead/destinazioni a cui l'utente corrente aveva accesso; si visualizzavano quindi solo i dati dei conti presenti in tale tabella e poi essa veniva svuotata all'uscita dal programma.
Ad esempio, in "Stampa documenti di magazzino" (BNMGSTBO) quando si lanciava la stampa si riempiva prima la tabella con i lead/conti a cui si ha accesso, in modo che poi si stampavano solo i dati di tali conti; se si lanciava una nuova stampa, la tabella veniva svuotata e ripopolata ad ogni nuova stampa. Infine, la tabella veniva svuotata alla chiusura del programma.
Tale operazione di svuotamento/riempimento della tabella poteva causare rallentamenti nel caso in cui i lead/fornitori/clienti/destinazioni fossero una mole importante di record.
Inoltre, ogni programma che sfruttava la TTSUBQCRM andava a popolarla con un instid specifico, per cui, nella stessa sessione di Business si potevano avere per lo stesso utente dati duplicati all'interno della tabella, che alla fine conteneva tantissimi record.
Ad esempio: admin apre il programma BNMGSTBO, lancia la stampa che popola la TTSUBQCRM con instid 1. Contemporaneamente, senza chiudere il programma, apre anche BNORCONF e lancia la stampa, andando quindi a popolare la TTSUBQCRM con instid 2  la tabella temporanea contiene due volte lo stesso set di dati, uno per ciascun programma che si appoggia a tale tabella per i controlli CRM; per chi ha tantissimi lead/fornitori/clienti/destinazioni, il numero di record presenti quindi è molto elevato...

Ora, all'accesso a Business, all'utente viene attribuito un instid per TTSUBQCRM, specifico per la ditta su cui sta lavorando. Al primo accesso ad un programma che si basa sulla TTSUBQCRM per i controlli, essa viene popolata e NON viene più svuotata quando si effettua un'altra elaborazione o si chiude il programma. Tutti i programmi che si basano su tale tabella, quindi, useranno i dati già presenti, senza ricaricarli ogni volta. Ad es.:
Admin accede a Business sulla ditta PROVACRM >>> gli viene associato l'instid 4.
Admin accede a BNMGSTBO e lancia una stampa >>> la TTSUBQCRM non contiene record per l'instid 4, quindi viene popolata. Se si lancia un'altra stampa, la tabella temporanea non viene svuotata e ripopolata, ma si continuano ad usare i dati riferiti all'instid 4 dell'utente.
Se contemporaneamente Admin accede a BNCRGSOF, la TTSUBQCRM contiene già dati per l'instid 4 relativo all'utente quindi continua ad usare quelli senza ricaricarli o aggiungerne altri con instid specifico

Ogni volta che viene fatto quindi il cambio azienda, il cambio ditta o il cambio utente, la tabella TTSUBQCRM viene svuotata dei dati relativi all'utente/ditta precedenti e viene attribuito un nuovo instid per il nuovo utente/ditta.
Tali instid vengono memorizzati nel recent globale RECENT\CRM_Instid per utilizzarlo anche al successivo accesso a Business.
Nel caso in cui si effettui il cambio ditta all'interno di un programma (generalmente tramite pulsante "Strumenti – Cambio ditta", ad esempio in "Anagrafica clienti/fornitori"), i dati del "vecchio" instid non vengono svuotati, ma si aggiungono quelli relativi alla ditta su cui si lavora nel programma specifico. Ad es.:
Admin accede a Business sulla ditta PROVA, a cui viene attribuito instid 2; apre BNMGSTBO che popola la TTSUBQCRM per instid 2. Poi apre BN__CLIE ed effettua il cambio ditta accedendo alla ditta PROVACRM, associando a tale ditta l'instid 5
 i dati in TTSUBQCRM per l'instid 2 (riferiti alla ditta PROVA) non vengono svuotati perché servono ancora in BNMGSTBO e negli altri eventuali programmi aperti da menu
 in TTSUBQCRM vengono aggiunti i dati riferiti all'instid 5 per la ditta PROVACRM, che verranno usati solo da BN__CLIE

A livello di programmazione, ad ogni utente viene associata una lista di (ditta, instid) del tipo (oApp.User.dcCRMInstidPerDitta): [(PROVA, 1), (PROVACRM, 4)]
Quindi, quando faccio il cambio utente o il cambio azienda o il cambio ditta (da menu), la TTSUBQCRM viene svuotata per tutte le ditte/instid associati al vecchio utente. Quando chiudo Business, allo stesso modo, vengono cancellati tutti i record della TTSUBQCRM relativi all'utente corrente.

Ci sono tuttavia delle eccezioni: in BNCRLEAD, BN__CLIE, BN__ANAZ, BN__GOPE quando si effettua il salvataggio si svuota la TTSUBQCRM per i dati della ditta/instid corrente e la si ripopola. Questo perché potrebbero essere state fatte delle modifiche a conti/lead/accessi crm/operatori CRM che comportano il ricaricamento dei dati.
NB: i dati di TTSUBQCRM vengono ricaricati sempre, a prescindere dalla modifica fatta, per evitare di inserire troppi controlli...

Il ricaricamento automatico, tuttavia avviene solo per ditta/utente correnti. Potrebbe però capitare il caso in cui alcune modifiche fatte da un utente abbiano ripercussioni sui lead/conti accessibili da un altro utente. Ad es.:"Admin" e "Davide" accedono a Business contemporaneamente con due istanze diverse.
Ad "Admin" viene attribuito l'instid 1 e popolata la TTSUBQCRM con i dati relativi.
A "Davide" viene attribuito l'instid 8 e popolata la TTSUBQCRM con i dati relativi.
Poi l'utente "Davide" apre un lead a cui sono associati sia "Davide" sia "Admin", e rimuove l'accesso di "Admin". Al salvataggio del lead la TTSUBQCRM viene svuotata e ripopolata, ma solo per i dati relativi all'instid 8. Così facendo l'utente "Admin" continuerebbe ad avere accesso al lead finché la tabella temporanea non viene ricaricata (quindi, potenzialmente, finché non chiude Business...). In realtà >>> bisogna forzare l'aggiornamento dei dati anche di "Admin", facendo in modo che i vari programmi, pur rilevando dei dati nella TTSUBQCRM, non li considerino validi.
Si usano quindi delle opzioni di registro per gestire questa situazione:
- un'opzione in cui viene memorizzato per ogni utente/ditta/instid, la data/ora di caricamento dei dati in TTSUBQCRM
- un'opzione "globale" per ditta in cui viene memorizzata la data/ora in cui è avvenuta l'ultima modifica di una delle tabelle usate per determinare gli accessi CRM (in particolare anagra, destdiv, leads, accdito, accccrm, acclead).
 quando si deve popolare la TTSUBQCRM, se la data ultimo caricamento è inferiore alla data ultima modifica, allora viene svuotata degli eventuali record in essa presenti, così da forzarne l'aggiornamento; viceversa, i dati in essa presenti vengono considerati validi e continuano ad essere utilizzati dai vari programmi che si basano su di essa.

Negli altri programmi:
• dove viene fatta una UPDATE di ANAGRA o DESTDIV non viene forzato l'aggiornamento della TTSUBQCRM (ossia non viene aggiornata l'opzione CRM_UltaggTab) perché in ogni caso non verrebbero modificati dati rilevati per determinare se un conto deve essere inserito o meno nella tabella temporanea (ad esempio: usando la funzione "Crea anagrafica generale" da BN__CLIE, si crea anagen e si aggiorna anagra per riportare il codice anagrafica generale, ma non cambia il fatto che quel conto sia accessibile o meno dagli utenti)
• quando salvo un'anagrafica generale, invece, si forza l'aggiornamento della TTUSUBQCRM (principalmente per gestire il caso di inserimento e cancellazione, in aggiornamento non servirebbe. Tuttavia, come in BN__CLIE e BNCRLEAD, l'opzione viene memorizzata sempre per evitare di fare eccessivi controlli...meglio comunque aggiornare la TTSUBQCRM una volta in più che una in meno, mantenendo comunque migliorie prestazionali rispetto alle versioni precedenti)
• in "creazione lead da clienti/destinazioni" viene forzato l'aggiornamento della TTSUBQCRM
• in "GENERA ANAGRAFICA GENERALE DA ANAGRAFICHE CLIENTI/FORNITORI" non viene forzato l'aggiornamento della TTSUBQCRM
•In "VARIAZIONE CAMPI ANAGRAFICA CLIENTI/FORNITORI" viene forzato l'aggiornamento della TTSUBQCRM quando si cambia un agente dell'anagrafica che comporta la modifica dell'operatore associato al corrispondente lead ( >>> comporta una modifica di acclead)
• In "gestione obiettivi" viene forzato l'aggiornamento di TTSUBQCRM quando si converte un obiettivo in lead ( comporta una modifica di acclead)
• In "gestione customer service" NON viene forzato l'aggiornamento della TTSUBQCRM perché non è possibile modificare gli operatori associati al lead ( >>> è presente una form modale che va ad aggiornare acclead, ma non viene mai richiamata...)
• In "genera impegni cliente da offerte" viene forzato l'aggiornamento della TTSUBQCRM quando si crea il conto dal lead ( >>> comporta una modifica di anagra e anche di acclead)
• In "Importazione da E-commerce" si forza l'aggiornamento della TTSUBQCRM quando si importano destinazioni, clienti o lead
• In "Condivisione agenda" da consolle e-mail si forza l'aggiornamento della TTSUBQCRM perché aggiorna acccrm
• In "Condividi" da agenda si forza l'aggiornamento della TTSUBQCRM perché aggiorna ACCCRM