Gegevensmodel en architectuur

Gegevensmodel

• Bezoek: Een standaardobject dat eventgegevens vertegenwoordigt zoals Account, Plaats, Geplande begin- en eindtijd en Kanaal. Dit object is beschikbaar in Salesforce Clouds.

• Providerbezoek: Een extensieobject met een strikte één-op-één relatie met het Visit-object. Hierin worden branchespecifieke gegevens opgeslagen, zoals handtekeningstatus, bevestigingsvlaggen en nalevingsdetails.

Uitvoeringsgegevens en afgeleide relaties

Voor de uitvoering van bezoeken worden verschillende gegevensmodellen gebruikt, afhankelijk van het type activiteit.

Kinderen van aanbiedersbezoek: Een hoofd-/detailrelatie waarin uitvoeringsdetails worden opgeslagen als onderliggende records van het object Aanbiederbezoek.

• • Objecten:
    • ProviderVisitProductDetailing (Productdetails)
    • ProviderVisitDetailingProductMessage (Berichten)
    • ProviderVisitProductDiscussion (Productdiscussies)
    • ProviderVisitMarketingItem (achterblijven)
    • ProviderVisitRequestedSample (verzoeken rechtstreeks naar de behandelaar)
  • Afgeleide zoekopdrachten: De onderliggende objecten bevatten afgeleide opzoekvelden voor de recordpagina van het bezoek. Vanwege die relatie functioneren de objecten als gerelateerde lijsten, ook al zijn ze onderliggende objecten van het object Aanbiederbezoek. Dit vergemakkelijkt de rapportage en verbetert de zichtbaarheid van de objecten op de recordpagina Bezoek

Kinderen bezoeken: Een directe opzoekopdracht waarbij transactie- en samenwerkingsobjecten rechtstreeks worden gekoppeld aan het standaardobject Bezoek. Objecten:

• ProductUitbetaling (voorbeelddruppels)
• Onkosten
• Bezoeker (interne deelnemers)
• PresentatieForum (intelligente inhoud)

Nalevings- en handtekeningobjecten:

• • Digitale handtekening: Slaat de vastgelegde handtekening, het tijdstempel en de controledetails op en is gekoppeld aan het bezoek.
  • Definitie van nalevingsverklaring: Slaat de primaire gegevens op voor disclaimers en overeenkomsten.

Groepsbezoekstructuur

Interacties met meerdere deelnemers, zoals lunch en leren, worden gedefinieerd door een bovenliggende/onderliggende relatie:

• Een bovenliggend bezoek vertegenwoordigt de hoofdevent en locatie.
• Onderliggende bezoeken bevatten paren van Bezoek- en Leveranciersbezoek-records voor elke deelnemer. Deze onderliggende records worden gekoppeld aan de primaire record Bovenliggend bezoek door middel van een zelfopzoekopdracht voor het object Bezoek.

Architectuur van gebruikersinterface

Bezoekbeheer gebruikt architecturen van twee pagina's, afhankelijk van de fase van het bezoek.

• Betrokkenheidspagina bezoeken: Gebruik deze pagina om bezoeken te maken en bewerken. Het bevat twee deelvensters naast elkaar (een zijbalk en een formulier) voor realtime bezoekplanning en klantbetrokkenheid. De pagina is beschikbaar in zowel de mobiele app als de desktopsite door middel van een cachegeheugen voor metagegevens en is de belangrijkste werkruimte voor het beheer van klantgerichte activiteiten, zoals het delen van inhoud, het detailleren van producten en het uitgeven van monsters. De pagina is toegankelijk voor geplande (niet-ingediende) bezoeken.
• Recordpagina bezoeken: Gebruik deze pagina om bezoeken weer te geven, inclusief planning vóór het bezoek, beoordeling na het bezoek en controle. Het is een standaard Lightning recordpagina, geconfigureerd met behulp van de Lightning Appsamensteller. Het wordt ook gebruikt voor het beheer van niet-klantgerichte activiteiten, zoals het toevoegen van interne bezoekers, het vastleggen van onkosten, het bijwerken van accountbeoordelingen, het voltooien van beoordelingsvragen en het bijvoegen van bestanden.