AppExchange e pacchetti

Questa unita chiude il modulo Productivity and Collaboration con i due argomenti che l’esame tratta sempre insieme: cosa l’admin puo fare sull’app mobile senza scrivere codice e cosa succede quando si porta in org software scritto da qualcun altro. Sono domande molto “da Setup”: quasi sempre la risposta giusta e il nome esatto dello strumento, non il ragionamento.

L’app mobile non e un’app a parte

La Salesforce mobile app mostra la stessa org, gli stessi dati e gli stessi permessi di Lightning Experience. Quello che cambia e come il contenuto viene presentato, e quindi il lavoro dell’admin e quasi tutto di composizione: quali pagine esistono, quali azioni compaiono, cosa appare nel menu di navigazione.

Esiste anche la via del browser mobile: si arriva a Salesforce dal browser del telefono senza installare nulla. E utile per accessi occasionali, ma e l’app installata quella che l’esame considera l’esperienza di riferimento, perche solo li si ha la barra azioni, il menu di navigazione mobile e le funzioni del dispositivo (fotocamera, posizione).

Costruire una pagina e farla comparire nel menu

Quando serve una schermata che aggrega piu oggetti — per esempio i principali account e le principali opportunity in un unico posto, il classico launchpad — lo strumento e il Lightning App Builder, e il tipo di pagina da creare e l’App Page. Le altre due sono Record Page (il layout di un singolo record) e Home Page (la home di Lightning Experience): nessuna delle due diventa una voce di menu.

Creare la pagina non basta. In fase di attivazione dell’App Page si sceglie l’icona, si decide la visibilita e poi si usa la scheda Mobile Navigation: da li si aggiunge la pagina al Mobile Navigation Menu, cioe al menu dell’app Mobile Only dentro la Salesforce mobile app. La nuova voce si posiziona sotto Smart Search Items e si sposta trascinandola. Solo dopo questo passaggio la pagina esiste come elemento autonomo, con la sua icona, nella navigazione mobile.

Le azioni: due famiglie, due comportamenti

La barra azioni mobile e alimentata dalle quick action, e la distinzione fra i due tipi e una delle cose che l’esame chiede piu spesso.

La regola pratica: se il requisito dice «gia collegato al record che sta guardando», serve una object-specific action; se dice «da qualunque punto dell’app», serve una global action. Entrambe possono lanciare la creazione di un record, un Log a Call, un aggiornamento, un flow o un componente.

L’app mobile eredita poi il Page Layout e il compact layout (i campi in evidenza in cima al record). Le linee guida di design mobile spingono a tenere pochi campi per schermata e a ridurre i tempi di caricamento: le pagine Visualforce non diventano mobile-friendly da sole.

Visibilita e app menu

Chi vede cosa dipende dai profili: un’app Lightning compare nell’App Launcher solo per i profili a cui e assegnata, e le sue voci di navigazione rispettano comunque i permessi su oggetti e campi. Lato dispositivo, policy come timeout di sessione, PIN, dati offline e allowlist di IP si governano dalle Connected App Policies, ed e frequente affiancare un sistema MDM per distribuire l’app o preconfigurare l’host di login.

Branding: due livelli molto diversi

Personalizzare colori e logo dentro l’app standard e una cosa. Ben altra e pubblicare un’app che si scarica da App Store e Google Play con il nome dell’azienda, l’icona sullo store, l’icona sul dispositivo e i colori della schermata di caricamento: quella richiede Mobile Publisher, un programma a parte da attivare con il proprio referente Salesforce. Mobile Publisher confeziona l’app Salesforce (o un sito Experience Cloud) come applicazione autonoma, e la distribuzione puo essere pubblica sugli store o privata via MDM.

AppExchange: portare in org software di altri

Managed contro unmanaged

Da qui discende la risposta secca a un requisito ricorrente: se l’azienda pretende che i propri sviluppatori possano cambiare codice e metadati dopo l’installazione, l’unica opzione e il package unmanaged — accettando che non arrivera mai un aggiornamento e che i componenti pesano sui limiti dell’org. Nei managed, il subscriber puo comunque personalizzare alcune cose (i page layout, per esempio, e le modifiche sopravvivono agli upgrade), ma i componenti bloccati restano del fornitore. E gli upgrade vanno in una direzione sola: non si torna a una versione precedente.

Installare secondo le buone pratiche

Due mosse guidano quasi tutte le domande di installazione:

1. Mai in produzione per prima cosa. Si installa in un sandbox o in una Developer Edition e si prova li.
2. Si parte stretti. In fase di installazione si sceglie Install for Admins Only, Install for All Users o Install for Specific Profiles. Per un pilota su un gruppo ristretto, la scelta corretta e Install for Specific Profiles (o admin only con permessi concessi dopo): l’accesso si allarga sempre, togliere e piu doloroso.

Prima ancora, il listing su AppExchange e la fonte da leggere: descrizione, documentazione, recensioni, edizioni supportate.

Pubblicare: serve un permesso, non solo un account

Per offrire la propria soluzione, l’azienda deve essere iscritta al partner program e avere accesso alla Partner Community. Ma la domanda d’esame e piu fine: perche un collega possa creare e gestire il listing, l’amministratore dell’org partner deve invitarlo e assegnargli il permesso Listings nella console partner. Senza quel permesso non pubblica, per quanto l’azienda sia partner. Il ciclo di vita del prodotto e: si costruisce con il packaging managed, si crea il listing, si passa la security review di Salesforce, e solo dopo la soluzione e distribuibile.

Non solo app: prompt e flow

Il marketplace non distribuisce piu soltanto applicazioni complete. Accanto ad AppExchange c’e AgentExchange, dove si trovano asset per Agentforce — prompt template, azioni e topic per gli agenti — oltre a flow e componenti singoli, molti gratuiti (per esempio quelli di Salesforce Labs). Si installano con la stessa procedura di qualunque package, e spesso richiedono una configurazione post-installazione in Setup. Utile saperlo perche la guida d’esame cita esplicitamente prompt e flow fra i casi d’uso.

Trappole tipiche d’esame

• Creare la pagina non la mette nel menu. Un’App Page costruita in Lightning App Builder resta invisibile sul telefono finche non la si aggiunge al Mobile Navigation Menu in fase di attivazione. Se una risposta si ferma a «crea una Lightning App Page», e incompleta.
• Object-specific contro global. «Gia collegato al record aperto» = object-specific. «Da qualsiasi punto dell’app» = global. Le due si confondono perche entrambe compaiono nella barra azioni mobile.
• Branding nell’app standard contro Mobile Publisher. Icona sullo store, nome sullo store e splash screen non si ottengono da Setup: richiedono Mobile Publisher. Se la domanda nomina App Store o Google Play, la risposta e quella.
• Unmanaged = modificabile ma senza upgrade. Chi vuole modificare il codice sceglie unmanaged e perde gli aggiornamenti; chi vuole gli aggiornamenti sceglie managed e non tocca il codice. Non esiste l’opzione che fa entrambe.
• Pilota non vuol dire produzione per tutti. La coppia corretta e «prima in sandbox» + «installa per profili specifici». Risposte che installano in produzione per tutti gli utenti sono sbagliate anche quando il pilota e piccolo.
• Partner non basta per pubblicare. Serve il permesso Listings assegnato dall’admin dell’org partner alla singola persona: e un permesso, non un ruolo implicito dell’essere dipendente di un partner.