LLM Call is automatically enabled in Vault CRM. Vault Owners are automatically granted access to the llm_call__v object and the Markdown renditions stored within the markdown__v field on those records.

Veeva recommends using either the Data Lakehouse or Vault APIs to retrieve LLM Call records for external AI agents. For best results, utilize the Data Lakehouse with bulk ingestion into platforms like Databricks or Snowflake. Do not build custom API integrations to poll for LLM Calls.

Optional Configuration

Administrators and integration users can optionally be granted access to the llm_call__v object and its fields, as needed for reporting or business needs. Granting or withholding these permissions only affects access for the individual user. It does not change how the Markdown rendition is generated. Carefully assess whether any Vault users need access to the llm_call__v object.

Access to call2__v and related objects is not needed to view or access LLM Call. The Vault object, field, and record security models for Call and Call-related objects are not applied within the Markdown rendition.

If granted access, admins can view LLM Call records in the Business Admin section of Vault CRM.

When a user creates a call report, the system automatically generates a corresponding llm_call__v record containing the full English-language Markdown rendition with a front-matter header and a readable body. Although some IDs are included in the Markdown header, internal API names and record IDs are typically excluded from the readable body; all labels and picklist values resolve to standard English.

The system strips HTML from rich text fields, but transforms specific elements (for example, line breaks) into Markdown equivalents to preserve semantic meaning. To ensure data integrity, content is not summarized or otherwise revised for the Markdown rendition.

English is the only language used for LLM Call Markdown renditions, as the highest-availability language for most LLMs in use by the life sciences industry. If a field or picklist lacks an English translation, the Markdown rendition displays the untranslated label.

In the current release, supported data model elements include:

• call2__v header fields
• call2__v attendee information
• call_notes__v field on the call2__v object
• call2_detail__v records
• call2_key_message__v records

The rendition updates automatically whenever the parent call or any supported child or related objects are created, edited, or deleted. When a call2__v record is deleted , the system automatically deletes the corresponding llm_call__v record to keep data synchronized.

Considerations

• Ensure fields containing Protected Health Information (PHI) or Personally Identifiable Information (PII) have the Contains PHI/PII attribute set to True. These fields are automatically excluded from the Markdown rendition to maintain data compliance.
• Users with access to Call Reporting require no additional configuration. The system automatically generates Markdown renditions when users create call reports.
• The system does not automatically generate LLM Calls for records created before LLM Call is enabled. To generate a document for an existing call, edit the call or a record on a supported call-related object.

The LLM Call Markdown rendition begins with a front-matter header containing field names and key data (for example, Call Datetime, Schema Version) to ground agents and allow them to perform subsequent queries if needed (for example, using the Account ID to find out more information about the call account). This is followed by the sectioned body in natural language.

• To retrieve LLM Call Data: Query the llm_call__v object or connect through the Data Lakehouse interface to extract plain language key-value pairs and sectioned text content.
• To handle long text entries: Scan the end of the text string for a "TRUNCATED" label. The system enforces strict character budgets to ensure the final document text stays within a 32,000-character maximum limit. Call reports with a significant volume of data may experience truncation—for example, a call report with 35 or more attendees and maximum use of the Call Text (call_notes__v) field may be truncated.

When designing prompts or parsing logic for AI agents or other downstream systems, always reference the current Vault CRM-provided schema version. The following downloadable examples are available here:

• Standard Call Report Schema
• Event Call Report Schema

Changes to the Markdown schema are not retroactively applied to existing LLM Calls; new schema versions only apply to LLM Calls generated or updated on a forward-going basis.

This schema mapping guide helps admins understand how schema data elements relate to Vault CRM fields and objects. The mappings are divided into three core categories: Header Metadata, Body Sections, and Related Activity.

Header Metadata

The header consists of system metadata and core identifiers that serve as query handles. These elements are included within the header block in the order shown below, and are typically omitted if the value is null (unless noted as a count key, which defaults to 0).

Schema Element	Source	Source (Field or Logic)
Schema Version	N/A - Constant value	N/A - Constant value
Call Record ID	call2__v	id
Vault ID	Vault Instance	Vault ID
Call Object Type	call2__v	object_type__v
Account ID	call2__v	account__v
User ID	call2__v (child)	user__v
Parent Call ID	call2__v	parent_call__v
Account	call2__v	account__v
Event	em_event__v or medical_event__v	Resolved Name (String)
Event ID	em_event__v or medical_event__v	id
Event Type	Derived	Derived from Event object type
Owner	call2__v	ownerid__v
Territory	call2__v	territory__v
Date	call2__v	call_date__v
Datetime	call2__v	call_datetime__v
Channel	call2__v	call_channel__v
Call Type	call2__v	call_type__v
Location	call2__v	location_text__v
Duration	call2__v	duration__v
Status	call2__v	call2_status__v
Is Sampled Call	call2__v	is_sampled_call__v
Group Call	Derived	Derived based on call structures
Unique Activities	call2__v	zvod_unique_group_activities__v
Attendees	call2__v	attendees__v
Products Detailed	Rollup	Count of call2_detail__v
Key Messages	Rollup	Count of call2_key_message__v

Body Sections - Repeating Collections (Tables)

These tables render in the body of the markdown output. If a collection contains no records, the section header and table are omitted.

Attendees (Group / Parent Calls Only)

Object Sources: Child call2__v records of the parent call, and attendee_list__v for non-HCPs.

Sort Order: Account attendees sorted alphabetically by name, followed by User attendees (organizer first).

Column Label	Source Object	Source Field
Attendee	call2__v	entity_display_name__v
ID	call2__v	account__v or user__v
Type	call2__v	account__v.object_type__v
Activity summary	call2__v	N/A, per-attendee rollup
Child call ID	call2__v	id
Note Below Table	call2__v	attendee_list__v

Products Detailed

Object Source: call2_detail__v

Sort Order: Ordered by detail_priority__v field value in ascending order, then by Product Name.

Column Label	Source Object	Source Field
Priority	call2_detail__v	detail_priority__v
Product	call2_detail__v	product__v
Type	call2_detail__v	type__v
Detail Group (Optional)	call2_detail__v	detail_group__v

Key Messages

Object Source: call2_key_message__v (only includes records where clm_presentation_name__v is null)

Sort Order: Ordered by display_order__v field value in ascending order, then by Product Name.

Column Label	Source Object	Source Field
Product	call2_key_message__v	product__v
Key Message	call2_key_message__v	key_message__v
Reaction	call2_key_message__v	reaction__v

Related Activity (Prose-like Sections)

The following elements are rendered in standard Markdown bold-label prose blocks.

Call Notes

The Call Notes section utilizes standard plain text mapping fields residing on the main call object (call2__v). It maps any relevant pre-call, next-step, comment, or meeting narrative attributes from the primary call2__v record:

• Pre-call: pre_call_notes__v field content
• Call Text: call_notes__v field content; forms main body of the Call Notes section in the Schema
• Next: next_call_notes__v field content
• Comments: comments__v field content