Un amministratore Salesforce risponde in continuazione a due domande che l’esame tiene vicine perché in produzione lo sono: chi sta entrando e che cosa rappresenta il record che sta guardando. La prima è la catena dell’autenticazione — da dove si entra, come si prova la propria identità, quanto dura il privilegio che si ottiene. La seconda è il modello di account: azienda, persona, o persona che lavora per più aziende. Sono entrambe materia di scenario: la guida non chiede definizioni, chiede le implicazioni di una scelta già fatta da qualcun altro.

Da dove si entra: My Domain e le sue due policy

My Domain sostituisce l’URL di login generico con un sottodominio dell’org (https://azienda.my.salesforce.com) ed è il prerequisito pratico del single sign-on, degli auth provider e del lavoro su più org nello stesso browser. Sotto Setup → My Domain → Routing and Policies stanno due interruttori che sembrano lo stesso interruttore e non lo sono:

  • Prevent login from https://login.salesforce.com riguarda gli utenti: chiude la porta dell’interfaccia, compresi i vecchi URL di istanza.
  • Prevent SOAP API login from https://login.salesforce.com riguarda le integrazioni: ogni client che chiama login() su quell’endpoint smette di autenticarsi.

La conseguenza è meccanica, non un caso limite: middleware, script, tool ETL e connettori cablati su login.salesforce.com si rompono la notte stessa dell’attivazione, e il sintomo arriva come errore di autenticazione del job notturno, non come reclamo di un utente. La correzione non è spegnere la sicurezza ma puntare il client al My Domain. Prima di attivare, l’opzione Log redirections serve proprio a scoprire chi sta ancora bussando alla porta vecchia. Sulla stessa pagina vive il branding della login page: logo, colore di sfondo, right frame URL.

Come si prova l’identità: verifica, intervalli IP, SSO

Al primo login da un indirizzo IP mai visto, Salesforce chiede un codice di verifica. È il comportamento predefinito, ed è quello che esaspera chi lavora dagli alberghi e dalle sedi dei clienti. Qui l’esame contrappone due impostazioni dal nome simile e dall’effetto opposto.

Trusted IP Ranges Login IP Ranges
Dove si imposta Setup → Network Access, vale per tutta l’org sul profilo, vale per chi lo ha
Che cosa fa salta la richiesta del codice di verifica blocca il login fuori dall’intervallo
Chi sta fuori dall’intervallo entra comunque, con verifica non entra affatto

Uno scenario che dice «i commerciali sono stufi del codice, ma devono poter lavorare anche fuori sede» chiede i Trusted IP Ranges sull’intervallo della VPN aziendale: usare lo stesso intervallo come Login IP Range toglierebbe il fastidio chiudendo fuori chiunque non sia in VPN. Sul profilo vivono anche le Login Hours, che non buttano fuori l’utente già collegato ma gli impediscono di proseguire.

Il single sign-on sposta la verifica altrove. Salesforce distingue l’SSO inbound — l’utente si autentica presso l’identity provider aziendale e arriva in Salesforce senza digitare credenziali Salesforce — dall’outbound, in cui è Salesforce a fare da identity provider verso altri servizi. Il protocollo dell’esame è SAML 2.0, la configurazione è reciproca (Salesforce riceve certificato ed endpoint dell’IdP; l’IdP riceve Entity ID e login URL del service provider) e il legame fra le due identità è di norma il Federation ID, che deve essere univoco nell’org. Due punti che l’esame verifica sempre: l’utente Salesforce continua a esistere con il suo profilo e i suoi permission set — l’SSO decide se entri, non che cosa puoi fare — e My Domain resta il presupposto della configurazione.

Quanto dura il privilegio: profilo, permission set, sessione

Strumento Quanti per utente Che cosa porta Quando decade
Profilo uno solo permessi di base, app e page layout di default, record type disponibili, login hours, login IP ranges mai, finché resta assegnato
Permission set molti permessi aggiuntivi su oggetti, campi, app quando si toglie l’assegnazione
Permission set group molti raggruppa permission set in una persona operativa idem
Muting permission set dentro un gruppo toglie un permesso, ma solo dentro quel gruppo —
Permission set session-based molti permessi attivi solo a sessione attivata alla fine della sessione

Il pattern raccomandato è profilo minimo (Minimum Access - Salesforce) più permission set: meno profili da mantenere e meno accessi ereditati per distrazione. Il muting è lo strumento più frainteso del gruppo: azzera un permesso per chi è nel gruppo, ma non lo toglie a chi lo ottiene dal profilo, da un permission set assegnato direttamente o da un altro gruppo. E mutare Read su un oggetto muta a cascata anche Create, Edit, Delete, View All e Modify All, perché senza lettura le altre operazioni non stanno in piedi.

Il permission set session-based è la risposta corretta quando lo scenario chiede un accesso elevato temporaneo e legato alla sessione: si spunta Session Activation Required, l’assegnazione da sola non basta, la sessione va attivata (tipicamente da un Flow o via API) e il privilegio sparisce quando la sessione finisce, per logout o per timeout. Per un oggetto sensibile aperto solo mentre si lavora una pratica approvata — un Settlement__c — è esattamente questo, non un permission set ordinario che poi resta assegnato per sempre.

Che cosa rappresenta il record: account, persona, persone in più aziende

Situazione Modello corretto
Azienda con dipendenti da contattare business account con i suoi contact
Consumatore singolo, libero professionista senza datore person account
Una persona che lavora per più aziende Contacts to Multiple Accounts

Il person account fonde i campi di Account e Contact in un oggetto solo che rappresenta una persona: la creazione genera due record, un account e un contact, che si aggiornano insieme. Si abilita in Setup, ha almeno un record type dedicato (se ne possono creare altri per categorie diverse di clienti) e — dettaglio che l’esame usa come trappola secca — una volta abilitati non si disabilitano più. Alla richiesta «accendiamoli per un trimestre e poi si vede» la risposta corretta è che non è reversibile: si prova in sandbox e poi si decide.

Da lì discende il sintomo classico del giorno dopo: alcuni utenti cliccano New sulla tab Accounts e vengono portati dritti al form del business account, senza che venga offerta la scelta. Non è un difetto della funzionalità, è accesso al record type: il profilo (o un permission set) di quegli utenti non ha il record type person account fra quelli disponibili, oppure ha un record type di default che salta la schermata di scelta.

Quando invece la persona esiste già e serve in più aziende, la risposta non è duplicarla. Contacts to Multiple Accounts mantiene un solo record contact: l’account indicato in Account Name è la relazione diretta, le altre sono relazioni indirette, e il contatto compare nella Related Contacts list di tutti gli account coinvolti, con un ruolo per relazione ed eventuali campi personalizzati. L’account hierarchy costruita con Parent Account è un’altra cosa: lega aziende ad aziende, non persone ad aziende.

Una precisazione che conviene dichiarare invece di nascondere: alcune pagine affermano seccamente che i person account «non hanno contatti propri». È vero che non si creano contatti figli come su un business account, ma le relazioni indirette possono coinvolgere i person account quando l’org abilita l’opzione dedicata. Se una domanda poggia su un «non si può», verificalo nella tua org prima di fidarti.

Trappole tipiche d’esame

  • Le due policy di My Domain non sono intercambiabili. A spegnere un’integrazione notturna è quella sulla SOAP API, non quella sugli utenti: se lo scenario parla di middleware o di job schedulati, la risposta è aggiornare l’endpoint del client al My Domain, non riaprire login.salesforce.com.
  • Trusted IP Range salta la verifica, Login IP Range blocca il login. Alla domanda «togliamo il codice di verifica a chi arriva dalla VPN» la risposta giusta è il Trusted IP Range org-wide; il Login IP Range sul profilo risolve il fastidio impedendo di lavorare da qualsiasi altro posto.
  • I person account non si spengono. Qualsiasi opzione che prometta una prova reversibile («lo attiviamo e poi lo togliamo») è sbagliata per costruzione: la prova si fa in sandbox.
  • «New non mi offre il person account» è un problema di record type, non della feature: si concede il record type sul profilo o via permission set, e si controlla il record type di default.
  • Temporaneo e legato alla sessione significa session-based permission set. Un permission set normale, un permission set group o un cambio di profilo danno lo stesso accesso ma non lo tolgono da soli; e il muting non revoca ciò che l’utente riceve dal profilo o da un permission set assegnato direttamente.
  • Persona in due aziende: un contact solo. Duplicare il contatto, o creare un person account accanto al contact, sono le risposte-esca; Contacts to Multiple Accounts esiste proprio per evitarle, e Parent Account risolve un problema diverso (le gerarchie fra aziende).