Data Model and Architecture

Data Model

• Visit: A standard object that represents event information such as Account, Place, Planned Start and End Time, and Channel. This object is available across Salesforce clouds.

• Provider Visit: An extension object with a strict one-to-one relationship to the Visit object. It stores industry-specific data such as signature status, confirmation flags, and compliance details.

Execution Data and Derived Relationships

Visit execution uses different data models depending on the type of activity.

Provider Visit Children: A master-detail relationship in which execution details are stored as child records of the Provider Visit object.

• • Objects:
    • ProviderVisitProductDetailing (Product Details)
    • ProviderVisitDetailingProductMessage (Messages)
    • ProviderVisitProductDiscussion (Product Discussions)
    • ProviderVisitMarketingItem (Leave-behinds)
    • ProviderVisitRequestedSample (Direct to Practitioner Requests)
  • Derived lookups: The child objects contain derived lookup fields to the visit record page. Because of that relationship, the objects function as related lists even though they're children of the Provider Visit object. This makes reporting easier and improves the objects' visibility on the Visit record page

Visit Children: A direct lookup in which transaction and collaboration objects link directly to the standard Visit object. Objects:

• ProductDisbursement (Sample Drops)
• Expense
• Visitor (Internal Attendees)
• PresentationForum (Intelligent Content)

Compliance and signature objects:

• • Digital Signature: Stores the captured signature, timestamp, and audit details and linked to the visit.
  • Compliance Statement Definition: Stores the primary data for disclaimers and agreements.

Group Visit Structure

Multi-attendee interactions, such as lunch and learns, are defined by a parent/child relationship:

• A Parent Visit represents the main event and location.
• Child Visits contain pairs of Visit and Provider Visit records for each attendee. These child records are linked to the primary Parent Visit record by using a self-lookup on the Visit object.

User Interface Architecture

Visit Management uses two-page architectures depending on the phase of the visit.

• Visit Engagement Page: Use this page to create and edit visits. It contains two side-by-side panels (a sidebar and a form) for real-time visit planning and customer engagement. The page is available in both mobile app and desktop site by means of a metadata cache and is the main workspace for managing customer-facing activities, such as sharing content, detailing products, and disbursing samples. The page is accessible for planned (unsubmitted) visits.
• Visit Record Page: Use this page to view visits, including pre-visit planning, post-visit review, and auditing. It's a standard Lightning record page, configured by using the Lightning App Builder. It's also used for managing non-customer-facing activities, such as adding internal visitors, logging expenses, updating account ratings, completing assessment asks, and attaching files.