Un’org Salesforce e’ prima di tutto un contenitore con un calendario, un orario di lavoro, una valuta e un elenco di persone che ci possono entrare. La sezione Configuration and Setup vale il 15% dell’esame e quasi meta’ delle sue domande nasce qui: impostazioni aziendali, configurazione dichiarativa dell’interfaccia, gestione degli utenti. Sono argomenti che sembrano banali finche’ non ti accorgi che l’esame ti chiede sempre quale leva, non se esiste.
Le impostazioni dell’org
Anno fiscale
In Setup, Fiscal Year offre due strade. Lo standard fiscal year e’ un anno di dodici mesi in cui scegli solo il mese di inizio (o di fine, a seconda di come e’ espressa l’impostazione): se l’azienda chiude i conti dal 1 aprile al 31 marzo, imposti il mese di partenza e Salesforce genera da solo tutti i periodi, i trimestri e le etichette usate da forecast e report. Il custom fiscal year serve solo quando il calendario non e’ fatto di mesi interi — le strutture 4-4-5, 13 periodi, settimane che non coincidono con i mesi — e ti obbliga a definire i periodi a mano.
La regola d’esame e’: se lo scenario dice «l’anno parte ad aprile» e aggiunge «senza definire i periodi uno per uno», la risposta e’ lo standard fiscal year con mese di inizio diverso da gennaio, non il custom. E ricordati che attivare i custom fiscal year e’ una scelta con conseguenze durature sull’org: si tratta come un interruttore che non si torna a spegnere con un clic.
Business hours, festivita’, locale
Business Hours definisce i giorni e le fasce orarie in cui l’azienda lavora, con il fuso orario relativo; Holidays sospende quelle fasce in date specifiche. Non sono un dettaglio estetico: le regole di escalation dei case e i milestone degli entitlement misurano il tempo dentro le business hours, quindi un case aperto il venerdi’ sera puo’ non scalare fino al lunedi’.
In Company Information vivono i default dell’org — Default Locale, Default Time Zone, Default Language e la valuta aziendale — e nella stessa pagina vedi lo spazio occupato e le licenze disponibili. Sono default: ogni utente puo’ sovrascriverli dalle sue impostazioni personali (Language & Time Zone). Il locale decide formato di data, numeri e ordinamento; la lingua decide le etichette. Confonderli e’ un classico.
Valute
Con la valuta singola tutto e’ espresso nella valuta aziendale. Attivando Activate Multiple Currencies (da Company Information) ogni record acquisisce un campo CurrencyIsoCode e l’org converte verso la corporate currency. Due cose da sapere a memoria: l’attivazione del multivaluta non si annulla, e la corporate currency non puo’ essere disattivata.
| Tassi di cambio semplici | Advanced Currency Management (ACM) | |
|---|---|---|
| Come funzionano | un tasso per valuta, valido «adesso» | tassi datati per intervalli di date (dated exchange rates) |
| Storico | i tassi precedenti non vengono conservati | ogni intervallo resta e continua a valere |
| Effetto di un aggiornamento | ricalcola anche i record chiusi in passato | i record usano il tasso del periodo della loro data di chiusura |
| Dove si applica | tutti i campi valuta | opportunity e opportunity product (e i loro rollup) |
Lo scenario tipico — «quando aggiorniamo il cambio, i valori convertiti delle opportunity chiuse nei trimestri passati cambiano» — ha una sola risposta: attivare ACM e usare i dated exchange rates. Attenzione pero’: ACM copre le opportunity, non ogni oggetto dell’org.
Configurazione dichiarativa della UI
L’App Manager governa le app Lightning: quali tab contengono, in che ordine, quali profili le vedono. Le list view sono la personalizzazione piu’ democratica: chiunque puo’ crearne una, filtrarla e decidere la visibilita’ (solo per me / per tutti gli utenti / per gruppi di utenti, da Sharing Settings). I list view chart invece si creano dal pannello grafici ma appartengono all’oggetto, non alla singola vista: una volta creati, compaiono su qualunque list view di quell’oggetto che l’utente puo’ vedere, con la sola eccezione di Recently Viewed.
Le azioni si dividono in due famiglie, e l’esame ci costruisce sopra domande intere.
| Global action | Object-specific action | |
|---|---|---|
| Dove compare | ovunque le azioni siano supportate, dal menu azioni globale | solo sui record dell’oggetto su cui e’ definita |
| Relazione col record | nessuna: il record creato nasce «orfano» | automatica: il record creato resta collegato al record di partenza |
| Dove si aggiunge | Global Publisher Layout |
sezione Salesforce Mobile and Lightning Experience Actions del page layout |
| Tipi disponibili | Create a Record, Log a Call, Update a Record, azioni custom (componenti, flow, Visualforce) | gli stessi, piu’ Send Email sui Case |
«L’agente registra la chiamata da un Case e il record risultante deve restare legato a quel Case, e l’azione non deve comparire ovunque»: azione object-specific di tipo Log a Call sul Case, aggiunta al page layout del Case. La stessa azione creata come globale soddisfa il primo requisito solo per caso e viola il secondo.
Il Lightning App Builder costruisce tre tipi di pagina — App Page, Home Page, Record Page — e la parte che l’esame interroga non e’ il disegno, e’ l’attivazione.
| Assegnazione | Record Page | Home Page |
|---|---|---|
| Org Default | si’ | si’ |
| App Default | si’ | si’ |
| App + Profilo | si’ | si’ |
| Record Type | si’ (App, Record Type e Profilo) | no |
| Form factor desktop / phone | si’, assegnabile separatamente | Lightning Experience (desktop) |
Le assegnazioni convivono: la piu’ specifica vince sulla piu’ generica, e l’org default e’ la rete di sicurezza per tutto cio’ che non e’ coperto. Sulla mobile app contano anche i compact layout, che decidono i campi mostrati nell’intestazione del record e nelle anteprime.
Utenti, licenze, uscite
Lo Username deve avere la forma di un indirizzo email ed essere univoco su tutta la piattaforma Salesforce, non solo nella tua org: se l’indirizzo aziendale e’ gia’ username in un’altra org (una sandbox, un’org di un altro reparto), Salesforce lo rifiuta. Si risolve con un suffisso — mario.rossi@azienda.it.crm — mentre il campo Email, che e’ quello a cui arrivano davvero i messaggi, resta l’indirizzo vero e puo’ ripetersi fra org.
Sullo stesso utente convivono tre cose diverse:
| Cosa | Che ruolo ha |
|---|---|
| User license (es. Salesforce, Salesforce Platform, Chatter Free) | definisce il perimetro massimo di funzionalita’ e quali profili sono selezionabili |
Feature license (caselle sul record utente, es. Marketing User, Knowledge User) |
abilita una singola funzionalita’ aggiuntiva sopra la user license |
| Permission set license (es. Sales Console User) | sblocca funzionalita’ che poi si concedono via permission set |
Profilo e permission set vengono dopo: il profilo porta i default (app assegnate, record type predefiniti, layout, login hours, login IP ranges), i permission set aggiungono permessi senza moltiplicare i profili.
Freeze contro deactivate e’ la coppia che l’esame ama:
| Freeze | Deactivate | |
|---|---|---|
| Blocca il login | si’, subito | si’ |
| Libera la licenza | no | si’ |
| Record posseduti | restano, invariati | restano: l’utente non si cancella, va sostituito come owner |
| Uso tipico | uscita improvvisa, mentre si ripuliscono accessi e proprieta’ | quando il riassetto e’ finito e serve la licenza |
Per il dipendente che se ne va di colpo, mentre il team ha bisogno di giorni per trasferire i record: freeze ora, deactivate dopo.
Per i metodi di login: My Domain da’ all’org un sottodominio proprio (azienda.my.salesforce.com), abilita SSO, authentication provider social, pagina di login brandizzata e permette di impedire l’accesso dagli URL generici di Salesforce. Le restrizioni di rete hanno due sapori opposti: le Login IP Ranges del profilo sono una lista di indirizzi consentiti (fuori da li’ il login e’ bloccato, senza scorciatoie), mentre i Trusted IP Ranges di Network Access sono permissivi (fuori da li’ si entra comunque, superando la verifica d’identita’). Le Login Hours del profilo limitano le fasce: chi e’ gia’ dentro quando scadono vede la pagina corrente ma non puo’ piu’ agire.
Infine, quando la stessa assegnazione si ripete a ogni assunzione — stesso permission set group, stesso public group, per tutti quelli con Department uguale a un certo valore — la leva giusta e’ una User Access Policy: filtri sui campi del record utente e azioni di grant o revoke su permission set, permission set group, public group, queue e licenze, applicate automaticamente alla creazione e/o all’aggiornamento dell’utente. Si abilitano da User Management Settings e si costruiscono da User Access Policies. Sono una funzionalita’ recente e in evoluzione: usale sapendo che una policy attiva tocca gli utenti esistenti solo quando il loro record viene aggiornato in modo da soddisfare i criteri, e che esiste un tetto al numero di policy attive (verificalo nella doc della tua release, non a memoria).
Trappole tipiche d’esame
- Standard contro custom fiscal year. Un anno che inizia ad aprile e’ ancora standard: basta cambiare il mese di partenza. Il custom serve solo per calendari non fatti di mesi interi (4-4-5, 13 periodi) e ti costringe a definire i periodi a mano.
- Aggiornare un tasso di cambio riscrive il passato. Senza Advanced Currency Management i tassi precedenti non vengono conservati e le opportunity gia’ chiuse cambiano valore convertito. La risposta e’ ACM con dated exchange rates, non «ricalcolare» o «bloccare i record».
- Global action contro object-specific action. Solo la seconda collega automaticamente il record creato al record di partenza e vive sul page layout di quell’oggetto. La global compare ovunque, e «ovunque» in molti scenari e’ esattamente il difetto.
- Il list view chart appartiene all’oggetto, non alla vista. Creato una volta, e’ disponibile su tutte le list view di quell’oggetto tranne
Recently Viewed: non va ricreato per ogni vista, ne’ e’ un componente da aggiungere alla Home. - Home page e record page non si assegnano allo stesso modo. Le record page accettano App + Record Type + Profilo e l’assegnazione per form factor; le home page si fermano ad app e profilo. Una risposta che parla di record type su una home page e’ sbagliata.
- Username univoco su tutta Salesforce, email no. L’errore «username gia’ in uso» non riguarda la tua org: si risolve cambiando lo
Usernamecon un suffisso, mai l’indirizzoEmail. - Freeze non libera la licenza, deactivate si’. Se lo scenario chiede di bloccare subito l’accesso ma i record vanno ancora trasferiti, la sequenza e’ freeze e poi deactivate; e un utente non si cancella mai.
- Login IP Ranges (profilo) blocca, Trusted IP Ranges (org) alleggerisce. Sono opposti: il primo e’ una allowlist rigida, il secondo salta solo la verifica d’identita’.