Introduzione
Il presente articolo offre informazioni sulla transizione verso il nuovo servizio di notifica:
- Risposte a domande frequenti
- Differenze significative rispetto alle notifiche legacy
- Considerazioni relative al trasferimento delle notifiche esistenti
Per la documentazione principale del nuovo servizio di notifica, si prega di consultare gli articoli della base di conoscenza:
Configurare le notifiche
Shortcode nelle notifiche
Eventi e condizioni delle notifiche
Per ulteriori informazioni sul programma di rilascio, consultare il post nella community: Rollout del nuovo servizio di notifica: piano di rilascio graduale | Community.
Trasferimento delle notifiche esistenti
Con la migrazione al nuovo motore di notifica, le notifiche esistenti verranno trasferite automaticamente. Pertanto, nella maggior parte dei casi non sarà necessario intraprendere azioni manuali. Si invita a consultare il resto di questo articolo per alcuni aspetti che potrebbero richiedere verifica.
Sintassi degli shortcode
In precedenza, gli shortcode inseriti nel corpo del messaggio erano delimitati da parentesi quadre, ad esempio [course_link]
.
Nelle nuove notifiche, tutti gli shortcode sono ora delimitati da doppie parentesi graffe, ad esempio: {{course_link}}
.
Quando la piattaforma sarà migrata al nuovo servizio di notifica, gli shortcode nelle notifiche esistenti verranno automaticamente convertiti nella nuova sintassi. Pertanto, non sarà necessario apportare modifiche manuali.
URL di base per i link nelle notifiche
Con la transizione al nuovo servizio di notifica, il sistema inserisce automaticamente nei link di notifica l'URL di base corretto per ogni destinatario. Di conseguenza:
- Ogni individuo che riceve un messaggio contenente uno shortcode come
{{course_link}}
riceverà un link che punta al proprio specifico cliente dell'impresa estesa. - Non sarà necessario configurare versioni separate di una notifica per ciascun cliente dell'impresa estesa.
- L'URL di base di una notifica non è più influenzato dal suo tipo di programmazione, né da chi modifica o salva la notifica.
Per ulteriori informazioni, si prega di consultare l'articolo Shortcode nelle notifiche > Link shortcode e domini dell'impresa estesa.
Shortcode per gli allegati di calendario
Con il nuovo servizio di notifica, il precedente shortcode [calendar_attachment]
non è più utilizzato. Invece, è ora possibile aggiungere allegati di calendario utilizzando un selettore nell'interfaccia utente.
Quando le notifiche esistenti contenenti il vecchio shortcode verranno migrate al nuovo servizio, il sistema rimuoverà automaticamente [calendar_attachment]
dal corpo del messaggio e aggiungerà il nuovo allegato di calendario.
Di conseguenza, potrebbe essere necessario rivedere e modificare manualmente il corpo del messaggio delle notifiche che precedentemente utilizzavano questo shortcode. Ad esempio, una frase come "Link del calendario per la sessione: [calendar_attachment]" diventerà troncata in "Link del calendario per la sessione: "
In tali casi, si consiglia di riformulare la frase in qualcosa come "Il link del calendario per la sessione è allegato a questo messaggio."
Notifica di completamento di un piano formativo da parte dello studente
Nel caso della notifica Lo studente ha completato un piano formativo attivata dagli utenti appartenenti a un ramo e inviata ai Power User o Superadmin, con la migrazione al nuovo motore di notifica, i destinatari riceveranno ora notifiche solo per gli utenti appartenenti al ramo attivatore. Non riceveranno più notifiche per alcun utente della piattaforma che completa il piano formativo.
Trasferimento dei programmi di notifica
Nel nuovo servizio di notifica, lo Scheduler supporta intervalli di tempo all'interno dei seguenti limiti consentiti:
Ore: 1→72
Giorni: 1→365
Settimane: 1→52
Mesi: 1→24
Le notifiche programmate legacy con intervalli di tempo al di fuori di questi limiti verranno trasferite applicando la seguente regola di conversione:
Convertire il valore all'unità di misura successiva fino a raggiungere un valore consentito. Ad esempio:
73 ore → 4 giorni
371 giorni → 53 settimane → 13 mesi
L'Ora è sempre impostato su 00:00 (corrispondente a mezzanotte) secondo il fuso orario definito.
Qualsiasi notifica con un intervallo di tempo che supera i 24 mesi (ad esempio 200 settimane) non verrà migrata.
Di conseguenza, dopo la migrazione delle notifiche preesistenti, potrebbe essere opportuno regolare l'intervallo di tempo ottenuto a seguito della conversione e impostare un orario diverso per l'invio della notifica.
Shortcode errati nei modelli migrati
Solo per le piattaforme sandbox che sono state migrate per la prima volta al nuovo servizio di notifica a dicembre 2024, a causa di un problema con alcuni modelli di messaggio, i seguenti tipi di notifica devono essere controllati e regolati manualmente:
Utente creato (dall'amministratore)
Utente creato (registrazione confermata)
Nuova versione dell’informativa sulla privacy
Nuova domanda per l'esperto
Più specificamente, le notifiche preesistenti basate sui modelli interessati potrebbero contenere shortcode errati come:
{{firstname}}
→ dovrebbe essere {{first_name}}
{{lastname}}
→ dovrebbe essere {{last_name}}
{{password}}
→ dovrebbe essere {{user_password}}
Oppure potrebbero contenere shortcode che non sono elencati tra quelli consentiti per quella notifica. Ad esempio: {{firstname}}
quando l'evento di notifica consente solo {{username}}
.
Attenzione! Questo problema non influisce sulle piattaforme che sono state migrate per la prima volta al nuovo servizio di notifica a gennaio 2025 o successivamente. Il suo impatto si limita esclusivamente alle sandbox inizialmente migrate a dicembre 2024 e successivamente ripristinate.
Cosa fare:
Se la propria piattaforma è tra quelle potenzialmente interessate, è necessario:
- Controllare eventuali notifiche preesistenti dei tipi di evento interessati e correggere manualmente eventuali gli shortcode errati. Gli shortcode consentiti e la loro sintassi corretta sono riportati nella sezione Shortcode dell'area di composizione del messaggio.
Suggerimento: il problema riguarda esclusivamente le notifiche preesistenti dei tipi di evento interessati che sono state migrate da legacy. I modelli sono stati successivamente corretti, pertanto quando si creano nuove notifiche di questi tipi, gli shortcode saranno corretti.
Migrazione delle notifiche che mirano a corsi eliminati
Dopo la transizione al nuovo motore di notifica, potrebbe emergere che alcune delle notifiche migrate preesistenti ora mirano a un pubblico più ampio rispetto a prima e vengono inviate inaspettatamente a un gran numero di utenti.
Se il problema si presenta, la causa potrebbe essere una notifica migrata che mira a corsi eliminati o inattivi. Tale notifica, infatti, non presenta nessun filtro di contenuto applicato (poiché tutto il contenuto mirato è stato eliminato o disattivato).
- Con le notifiche legacy, una notifica senza filtri di contenuto non veniva inviata.
- Con il nuovo servizio di notifica, una notifica senza filtri di contenuto (se salvata da un Superadmin) verrà attivata per tutti i corsi e piani formativi in piattaforma.
Azione consigliata: rivedere eventuali notifiche migrate che potrebbero aver precedentemente mirato a corsi eliminati o inattivi. Queste notifiche potrebbero ora essere interpretate come globali (non filtrate) e potrebbero essere consegnate più ampiamente del previsto.
Per ulteriori informazioni, si prega di consultare il post della community su questo argomento (si apre in una nuova scheda).
Migrazione delle notifiche dell'impresa estesa
Nel contesto di un'impresa estesa, se sono state migrate notifiche, a seconda di come sono state configurate, i destinatari e il campo di attivazione potrebbero essere diversi dopo la migrazione.
Con le notifiche legacy, i trigger (attivatori) e i destinatari di una notifica erano automaticamente limitati agli utenti del cliente dell'impresa estesa in cui ogni notifica era stata configurata e salvata. Questo avveniva anche in assenza di un filtro di ramo.
Di conseguenza:
- Era possibile configurare versioni multiple della stessa notifica, ognuna mirata agli utenti di un diverso cliente dell'impresa estesa.
- Questo poteva essere ottenuto senza un filtro di ramo, semplicemente salvando ogni notifica nel cliente appropriato dell'impresa estesa.
Con il nuovo servizio di notifica, i trigger e i destinatari di una notifica non sono più limitati al cliente dell'impresa estesa in cui la notifica è salvata. Pertanto, se esistono notifiche migrate configurate come descritto sopra, alcuni utenti potrebbero ora ricevere notifiche duplicate.
È possibile risolvere questo problema in due modi:
- Metodo 1: aggiungere filtri di ramo - Mantenere le diverse versioni della stessa notifica, ma inserire in ciascuna il filtro di ramo appropriato corrispondente al cliente dell'impresa estesa a cui dovrebbe mirare.
- Metodo 2: utilizzare una singola notifica - Sostituire le diverse versioni della stessa notifica con una singola notifica che funzionerà per i destinatari appartenenti a tutti i clienti dell'impresa estesa. Si ricordi che eventuali link shortcode utilizzeranno automaticamente l'URL di base corretto per ogni destinatario. Si ha anche la possibilità di utilizzare il shortcode {{extend_enterprise_logo}} per inserire dinamicamente il logo della piattaforma corretto.
Esempio: se erano configurate le seguente notifiche legacy:
- Utente iscritto a un corso senza filtri di ramo, salvato nel dominio A ; la notifica viene attivata solo dagli utenti appartenenti al dominio A e inviata solo ai destinatari appartenenti al dominio A
- Utente iscritto a un corso senza filtri di ramo, salvato nel dominio B ; la notifica viene attivata solo dagli utenti appartenenti al dominio B e inviata solo ai destinatari appartenenti al dominio B.
Dopo la migrazione al nuovo servizio di notifica, entrambe queste notifiche possono essere attivate da un utente appartenente a qualsiasi dominio e saranno inviate a destinatari appartenenti a qualsiasi dominio. Pertanto, un utente che si iscrive a un corso attiverà e riceverà entrambe le notifiche A e B.