Attività: i mattoni tracciabili della relazione

In Dynamics 365 un’activity è un record che rappresenta un’interazione collocata nel tempo. I tipi standard più rilevanti per lo scenario Sales sono:

  • Task — attività generica con data di scadenza, senza partecipanti multipli.
  • Phone Call — con direzione (incoming/outgoing) ed esito.
  • Email — integrata con la server-side synchronization verso Exchange.
  • Appointment — con organizzatore, partecipanti e sincronizzazione col calendario.

Tutte le attività condividono l’entità base ActivityPointer ed ereditano campi comuni come Regarding (il record collegato: Account, Lead, Opportunity…), Owner, Due date e soprattutto State (Open, Completed, Canceled) con il relativo Status Reason. Puoi definire anche custom activity abilitando l’apposita opzione sulla tabella: erediteranno automaticamente il comportamento della timeline.

La timeline e l’aggregazione delle attività

Il controllo Timeline aggrega su un singolo record tutte le attività il cui campo Regarding punta a quel record, insieme a note e post. A livello Associate conta sapere che:

  • La timeline mostra sia attività aperte sia chiuse, governate da filtri distinti; la vista di default può nascondere quelle completate.
  • Ordinamento e filtri (tipo di record, stato, autore, data) sono configurabili sul Timeline control del singolo form: due form possono quindi mostrare timeline diverse.
  • Un’attività è considerata conclusa quando il suo State passa a Completed o Canceled, non semplicemente cambiando lo Status Reason. Le attività aperte restano actionable e alimentano viste come “My Activities”.

Ownership: chi possiede il record

Ogni record owned in Dataverse ha un solo Owner, che può essere:

  • Un singolo utente, oppure
  • Un team (ownership team): il record è accessibile a tutti i membri secondo le loro security role, senza condivisioni singole.

L’ownership determina i diritti a livello di Business Unit e i controlli di sicurezza (User-level vs BU-level). Cambiare owner sposta il record nel perimetro di sicurezza del nuovo proprietario.

Assign vs Share

  • Assign cambia l’ownership: è un trasferimento, e il vecchio owner perde i diritti derivanti dalla proprietà (salvo altri accessi).
  • Share concede un accesso puntuale (Read, Write, Append, Assign…) a un utente o team senza cambiare l’owner. È additivo, granulare e revocabile: ideale per collaborazione temporanea.

Meccanismi di assegnazione

Oltre al cambio owner manuale, D365 offre assegnazione automatica basata su logica:

  • In Customer Service, Unified Routing e le classiche assignment rule instradano case e conversazioni (per capacità, skill, round-robin).
  • In ambito Sales/lead si usano tipicamente Power Automate flow per assegnare secondo criteri (territorio, round-robin, load balancing).
  • Le record creation and update rule convertono attività in ingresso (es. email) in record impostandone l’owner.

La differenza chiave: un cambio owner manuale è un’azione una-tantum decisa da una persona su un singolo record; un’assegnazione basata su regola applica una logica ripetibile, automatica e uniforme, garantendo coerenza e tracciabilità del routing quando i volumi crescono.

Connection e connection role

Le Connection modellano relazioni non gerarchiche e ad-hoc tra record (es. un Contact “Referral” verso un altro, o “Decision maker” su un’Opportunity). Un connection role definisce il ruolo e i tipi di record applicabili. Rispetto a una lookup dedicata sono più flessibili, ma non impongono referential integrity forte: usale per relazioni descrittive, non per legami strutturali su cui costruire logica di business.

Trappole tipiche d’esame

  • Scenario: un venditore lamenta che non vede le telefonate già registrate su un Account. → La causa più probabile è il filtro della timeline impostato su attività Open: le Phone Call chiuse (Completed) sono nascoste, non cancellate.
  • Scenario: vuoi che un collega collabori temporaneamente su un’Opportunity senza sottrarla al titolare. → Usa Share (accesso puntuale), non Assign: assign cambierebbe l’owner e toglierebbe i diritti al venditore originario.
  • Scenario: i lead vanno distribuiti equamente e in modo ripetibile tra il team inbound. → Serve un’assegnazione basata su regola (routing/flow), non un cambio owner manuale record per record.
  • Scenario: un record deve restare accessibile a un intero gruppo anche con turnover del personale. → Assegnalo a un owner team, così l’accesso segue l’appartenenza al team e non la condivisione individuale.
  • Scenario: devi indicare che un Contact è “influencer” su una trattativa, in modo riutilizzabile ma non vincolante. → Usa una Connection con connection role, non una nuova colonna lookup obbligatoria.