Developer Features in 24R1
Filters
Application Family
Tags
We are pleased to bring you the following additions and enhancements to Developer Portal features in 24R1.
Service Announcements
Section link for Service AnnouncementsService Announcements are changes that may affect existing integrations. Organizations should assess these features against their existing integrations and make updates where necessary.
Record Triggers Return Correct Fields for New Object Type
Section link for Record Triggers Return Correct Fields for New Object TypeWhen a record trigger executes due to an object type change, developers will now be able to get and set values on all object type fields that exist on the new object type. Previously, developers could only set values for object type fields that exist in both the old and new object types.
With this change, getNew() will now return null values for fields that are not set for the new object type and return non-null values for fields that are set for the new object type.
External URL Reverse IP Lookup Change
Section link for External URL Reverse IP Lookup ChangeExternal URL jobs are now sent from an IP address associated with Veeva Vault. Organizations who are currently allowinglisting by domain must update their rules to support the *.veevavault.com domains.
Non-consecutive Document IDs
Section link for Non-consecutive Document IDsWhen documents are created, Vault automatically assigns a document ID (note, this is different from Document Number). With v24.1, we are making changes to how Document IDs are generated to support future functionality. These changes will result in document IDs more frequently being non-sequential numbers.
There were already scenarios where Document IDs may not be sequential (i.e. due to document deletions), but these changes in v24.1 will result in Document IDs never being sequential.
Customers should assess any existing integrations if the Document ID is being used as a basis for document sequence. We do not recommend that the Document ID field be used as a means of identifying document creation order, but rather recommend the use of Document Number.
HVO Renamed to Raw with New One Billion Record Limit
Section link for HVO Renamed to Raw with New One Billion Record LimitHigh volume objects are now called raw objects. As we look to increase the scalability of our standard objects, we will begin treating high volume objects more like regular database tables, used for storing raw data. To make the purpose of these objects clearer, we are updating the terminology across our user and developer documentation and in the Vault UI and API, referring to this class of objects instead as raw objects.
There is now a limit of one billion records for raw objects. In addition, the data_store attribute for the Object MDL component now includes a value of raw. This change is backward compatible, and high_volume is still supported as an input value.
Global Changes
Section link for Global ChangesMerge Records API
Section link for Merge Records APIDuplicate records in Vault can happen due to migrations, integrations, or day-to-day activities. These duplicate records can be difficult to correct because of the many ways an object record can be referenced. For example, an object record may be referenced in both configuration and document and record relationships.
This feature allows developers with the Application: Object: Merge Records permission to merge two records using main_record_id and duplicate_record_id into a single record on Objects where the new setting, Enable Merges, is turned on. You can only turn on Enable Merges for custom objects.
During a record merge, Vault updates all inbound references from the Duplicate record to the Main record, including attachments. Field values on the Main record are not changed, and when the process is complete, the Duplicate record is deleted. SDK record triggers are not invoked during this process.
/api/{version}/vobjects/{object_name}/actions/mergeDevelopers can also use Vault Java SDK to invoke a merge records operation action using the RecordMergeRequest interface, and may also create Record Merge Event Handlers which can define custom logic for merging records. Only one event handler is allowed per object.
You can only initiate record merges through Vault API or the Vault Java SDK, and you can learn more about the Vault configuration required for merging records in Vault Help
Vault API v24.1
Section link for Vault API v24.1Global Changes
Section link for Global ChangesReference ID for Vault API
Section link for Reference ID for Vault APIX-VaultAPI-ReferenceId is a new API header that is defined by the client application calling Vault API. When using API v24.1+, and the API request includes a value for this header, Vault API will return the value in the API response and include it in the API usage logs when downloaded using Vault API v24.1+ or from the Vault Admin UI.
Vault API: Read and Delete Annotations
Section link for Vault API: Read and Delete AnnotationsIn API v24.1+, we have deprecated the following endpoints and replaced them with new endpoints. The new endpoints are identical, with the exception that they now end with the /file resource:
- Export Document Annotations to PDF
- Export Document Version Annotations to PDF
- Import Document Annotations from PDF
- Import Document Version Annotations from PDF
Previous API versions will continue to support the deprecated endpoints without /file. If you are upgrading an existing integration to API v24.1+, you must use the new endpoints which end in /file.
In addition, this feature introduces the new Read Annotations by Document Version and Type API endpoint that will return annotations as JSON, and allow users to paginate results and filter annotations by type using optional query parameters, such as annotation_types, limit, offset, and pagination_id:
/api/{version}/objects/documents/{doc_id}/versions/{major_version}/{minor_version}/annotationsThe above API also returns the Annotation ID id__sys, which can be directly called using the new Read Annotations by ID API endpoint:
/api/{version}/objects/documents/{doc_id}/versions/{major_version}/{minor_version}/annotations/{annotation_id}Developers may also get replies to a specific Annotation ID using the Read Replies by Parent ID endpoint, and use optional parameters limit, offset, and pagination_id:
/api/{version}/objects/documents/{doc_id}/versions/{major_version}/{minor_version}/annotations/{annotation_id}/repliesThe last update of this feature is the Delete Annotations endpoint, which can be used to delete annotations in a batch by providing document_id__v, major_version__v, major_version__v, and annotation_id__v as nodes in a JSON payload:
/api/{version}/objects/documents/annotations/batchAction Layouts: Summary Fields
Section link for Action Layouts: Summary FieldsThe 23R3.4 extension of the Action Layouts feature will introduce Summary Fields which will be accessible for Object and Objecttype components via MDL using the summary_fields attribute. Learn more about Object and Objecttype components.
For SDK, the summary_fields attribute can be obtained using the getSummaryFields() method for both the ObjectMetadata and ObjectTypeMetadata interfaces.
Learn more in the javadocs
New Endpoints
Section link for New EndpointsDirect Data API
Section link for Direct Data APIThe Direct Data API is a new class of API that provides high-speed read-only data access for Vault applications. Direct Data is a reliable, easy-to-use, timely, and consistent API for extracting Vault data. Using the API, customers can easily replicate Vault data in external data warehouses and data lakes.
The Direct Data API is an add-on license available for any Vault. When enabled, it will generate .gzip files containing several extracts. Extract CSVs include object records, document version metadata (excluding annotation count fields) picklists, and audit data.
There are three types of Direct Data files:
- Full: contains a complete set of data starting from the time the Vault was created to the current date published once a day.
- Incremental: contains an incremental set of data published for each 15-minute interval.
- Log: contains the Login, System, Object, and Document audit trails for a single day.
Learn more about the Direct Data API.
Bulk Rendition Operations
Section link for Bulk Rendition OperationsAs a result of a configuration change or migration project, there may be a need to re-render a substantial amount of documents. This new endpoint accepts a CSV file with document IDs to initiate a bulk re-render operation.
/api/{version}/objects/documents/batch/actions/rerenderView this endpoint in the v24.1 Vault API Reference.
End Session Endpoint
Section link for End Session EndpointThis new Vault API endpoint ends a Vault session. This allows integrations to end the Vault session instead of letting the session expire. If a user has more than one active session, ending one session does not affect the user's other sessions. For example, ending a user’s API session will not affect their active UI sessions.
/api/{version}/sessionView this endpoint in the v24.1 Vault API Reference.
Existing Endpoints
Section link for Existing EndpointsWarnings and Error Messages in API Usage Logs
Section link for Warnings and Error Messages in API Usage LogsAPI Usage Logs will now include error and warning messages that appear in the CSV file output. New columns will include api_response_warning_message and api_response_error_message.
Additionally, the X-VaultAPI-ReferenceId header will be included in the API Usage Logs with column reference_id.
These columns are included when downloaded using the Vault UI or API v24.1+.
New Object Audit Fields in CSV Exports and API
Section link for New Object Audit Fields in CSV Exports and APIThe object audit API (CSV and JSON) and data exports from the Vault UI (CSV) now include new fields that display the API names for fields, objects, new values, and old values. The affected endpoints are:
/api/{version}/vobjects/{object_name}/{object_record_id}/audittrail/api/{version}/audittrail/object_audit_trailThese new fields make it easier to join audit data with other Vault data and to perform additional analysis of audit data in external systems. This feature is automatically part of API v24.1.
Workflow Initiators Select Task Assignment Type
Section link for Workflow Initiators Select Task Assignment TypeVault now allows workflow initiators to select whether a task is assigned to Any or Every participant in a participant control of a workflow start step. This choice is enabled when configuring a workflow task and is stored in the MDL of the workflow component as the following XML tag <vwf:assignmentType type="runtimeChoice" />.
When using Vault API to start a workflow where workflow initiators can select the assignment type, the system will expect a value of assigned (assigned to all users) or available (available to any user) for the {participant_group}.assignment_type__c body parameter.
Learn more about starting a workflow with Vault API.
Workflow API Error Type Updates for Adding Participants
Section link for Workflow API Error Type Updates for Adding ParticipantsWhen using the Initiate Workflow Action endpoint to add participants or reassign tasks, if the workflow is configured to use either the Use Role as Participants or Use Custom Action to Define Participants option on participant controls, the API now returns an INVALID_DATA error type if the attempted action is not consistent with the participant control settings.
Binder Limits
Section link for Binder LimitsVault now has clearly documented and enforced limits for Vault Binders to ensure good binder performance. Developers will be able to use binders in a predictable and easy to understand way. For all API versions, the following limits now apply to binders:
- Binders cannot exceed 50,000 nodes, including component binders. If a binder has reached its limit, binder nodes cannot be added to the binder or any of its component binders, even if the component binders have not reached the 50,000 node limit.
- Binders cannot be versioned via Create Draft or copied if it exceeds 10,000 nodes, including the nodes within component binders. Vault will still execute the Set New Major Version entry action on binders which exceed 10,000 nodes.
These limits will apply to the following endpoints for all API versions:
/api/{version}/objects/binders/templates/{template_name}/bindernodes/api/{version}/objects/binders/{binder_id}/documents/api/{version}/objects/binders/{binder_id}/sections/api/{version}/objects/binders/templatesIf your organization has binders that are currently over any of these limits, the Veeva Account Team will be reaching out directly.
Document Templates Limit
Section link for Document Templates LimitVault now has clearly documented and enforced limits for Basic and Controlled Document Templates to ensure reliable document template performance.
- Each Vault now has a limit of:
- 50 document templates at the Base Document type
- 500 document templates per document hierarchy
- 5,000 document templates per Vault
These limits will apply to the following endpoints for all API versions:
/api/{version}/objects/documents/templates/api/{version}/objects/{documents_or_binders}/{id}/versions/{major_version}/{minor_version}/lifecycle_actions/{name__v}If your organization has document templates that are currently over any of these limits, the Veeva Account Team will be reaching out directly.
Action Layouts: Layout Profiles
Section link for Action Layouts: Layout ProfilesAdmins can now configure Layout Profiles that can define what Layouts are available to users on object records. With this enhancement, as new Layouts are configured on objects, customers can also assign what each user should see by default and what additional layouts should be available to them to switch between.
In API v24.1, when using the Create Object Records or Update Object Records endpoints to create or update Users, a new standard field called layout_profile__sys will be available.
/api/{version}/vobjects/{object_name}/api/{version}/vobjects/{object_name}This feature adds the new Layoutprofile component type to all Vaults.
Action Layouts: Layout Pages
Section link for Action Layouts: Layout PagesAdmins can now optionally configure up to 10 separate Pages in a Layout. Pages contain sections to allow for grouping them into more focused displays so that users can navigate between each Page based on the context and work to be done. By default, all existing layouts will remain unchanged, but the user interface for the left-hand navigation will appear slightly cleaner, and users will have the option to minimize the menu, allowing for a full-screen view.
In API v24.1, the Retrieve Page Layout Metadata endpoint will now include information (Label, Name, and Section) on any configured Pages, if more than one exists in a given layout. In addition, the Retrieve Page Layouts and Retrieve Page Layout Metadata endpoints will include additional information (such as Description, Status, Default, and Display Lifecycle Stages).
/api/{version}/metadata/vobjects/{object_name}/page_layouts/api/{version}/metadata/vobjects/{object_name}/page_layouts/{layout_name}This feature adds the following attributes to the Pagelayout component type:
default_layoutactivedescriptiondisplay_lifecycle_stages
Action Layouts: Layout Rules Enhancement
Section link for Action Layouts: Layout Rules EnhancementTo further enable the flexibility in these Layout changes, we have also enhanced Layout Rules.
Layout Rules are applied to each Layout and any Layout Pages within, but with the introduction of Layout Pages, rules can now be defined to hide or show Views and Pages within Layouts. Additionally, a new Layout Selection Rule is available called Focus On, which allows Admins to define criteria for overriding a default Layout.
There is also a new Display as Required option, which allows fields to be displayed as required fields based on the Layout Rule Expression - this can reduce the potential for users to encounter Entry Criteria errors by ensuring that fields display as required in the right circumstances.
In API v24.1, the Retrieve Page Layout Metadata endpoint will now include additional layout rule information, such as hiding view and pages, requiring field input and displaying view as selected.
/api/{version}/metadata/vobjects/{object_name}/page_layouts/{layout_name}This feature adds the following attributes to the Layoutrule component type:
hide_layoutfocus_on_layouthidden_pagesdisplayed_as_required_fields
Action Layouts: Additional Improvements
Section link for Action Layouts: Additional ImprovementsUsers can now create up to 50 custom layouts per Object - Object Type Pair, regardless of how many system or standard layouts there are. The previous limit was 20 custom layouts.
Application-Specific Endpoints
Section link for Application-Specific EndpointsClinical: EDL Override: Automation, Template Hierarchy, and Usability Enhancements
Section link for Clinical: EDL Override: Automation, Template Hierarchy, and Usability EnhancementsA new Vault API endpoint will be made available to generate Milestone Documents in bulk. The endpoint will accept a CSV file of up to 500 records.
/api/{version}/app/clinical/milestone/actions/generatemilestonedocumentsTOLABEL
Section link for TOLABELIn VQL, the TOLABEL() function will return the localized label of referenced components for the lifecycle states and picklist values of standard volume objects. Raw objects (formerly high volume objects) are not currently supported.
With this function, developers no longer need to convert and match name values to labels with a separate API call or hard-coded dictionary. This allows the API call to retrieve user-facing values in a single step.
Learn more about the TOLABEL() function.
Document Attachments
Section link for Document AttachmentsVQL queries can now access document attachment metadata via the attachments__sysr relationship. Developers must query attachments as subqueries in the SELECT or WHERE clauses. Document attachment subqueries support the ALLVERSIONS option.
Learn more about querying document attachments.
SDK Job Enhancements: VQL for SDK Jobs
Section link for SDK Job Enhancements: VQL for SDK JobsTo allow better control over SDK jobs, developers can now use the job_instance__sys VQL query target to find a running job and retrieve the job status and other job metadata.
Learn more about querying job instances.
Vault Java SDK
Section link for Vault Java SDKGlobal Changes
Section link for Global ChangesUser Object: Trigger Support
Section link for User Object: Trigger SupportVault now supports SDK record triggers on the user__sys object. Record triggers are only invoked when changes are made directly to the user__sys object on the Vault. Triggers on the user__sys object are not invoked for domain attribute updates (such as first name or last name) originating from other Vaults.
Learn more about user triggers.
New Interfaces & Methods
Section link for New Interfaces & MethodsRetrieve Vault Domain Name
Section link for Retrieve Vault Domain NameA new method, getDomain(), is now available in the VaultInformation interface that can be used to retrieve the domain name for a given Vault.
Document Lifecycle Services SDK
Section link for Document Lifecycle Services SDKThis feature introduces Document Lifecycle Services to the Vault Java SDK to retrieve configuration metadata about document lifecycles and lifecycle user actions. It also provides methods to execute user actions and state changes on documents.
Learn more about Document Lifecycle Services.
New capabilities for Annotations
Section link for New capabilities for AnnotationsVault Java SDK will now support creating and editing text annotations using coordinates.
When retrieving annotations via SDK, it will also include Modified by User (modified_by_user_sys) and Modified Date Time (modified_date_time_sys) fields. The values of fields will default to Created By and Created Date information when the last modified information does not exist for an annotation.
Learn more about Annotation Services.
SDK Job Enhancements: Cancel SDK Jobs
Section link for SDK Job Enhancements: Cancel SDK JobsDevelopers can now cancel an SDK job using the cancelJob() method in the Vault Java SDK. Custom SDK code can only cancel custom SDK jobs. This can be used to avoid multiple async jobs running at the same time, which could lead to inaccurate results.
SDK Job Enhancements: Job Task Retry
Section link for SDK Job Enhancements: Job Task RetryDevelopers can now retry a JobTask during SDK job execution using the setRetry(Boolean retry) method. Tasks can only be retried up to five (5) times, and the SDK must be annotated as idempotent=true. This feature can be used to increase the resilience of code in case of temporary errors, such as thread lock conflict or unavailable system resources.
SDK Job Enhancements: Retrieve Job Owner
Section link for SDK Job Enhancements: Retrieve Job OwnerDevelopers can now get the owner(s) of a job or the initiating user of a one-time job using the getJobOwner() method. This function can be used to alert the job owner about the status of the job.
The returned JobOwner provides two methods:
getId()to retrieve the user or group IDgetType()to determine whether the owner is a user or a group
EDL SDK: Manual Matching of Documents
Section link for EDL SDK: Manual Matching of DocumentsTo support customers who use EDL manual matching, we are introducing an SDK interface to enable the manual matching and unmatching of documents to EDL Items. In comparison, the API can be used to manually add, remove, lock, and unlock documents from EDL Items, but it does not support excluding and including automatically matched documents.
The EDL service provides methods to perform the following actions for manual matching:
- Add and remove a document
- Lock and unlock a document
- Exclude and include an automatically matched document
Existing Interfaces & Methods
Section link for Existing Interfaces & MethodsRecord Service Enhancements
Section link for Record Service EnhancementsThis feature enables developers to change the object type of a record as well as to save a record in migration mode via the Java SDK Record Service.
Two optional methods are added to RecordBatchSaveRequest.Builder:
Builder withAllowObjectTypeChange(boolean allowObjectTypeChange)Builder withMigrationMode(boolean migrationMode)
If migrationMode is set to true, the system will allow the creation or update of object records in any lifecycle state or state type. Additionally, Vault bypasses entry criteria, entry actions, validation rules, event actions, and reference constraints when creating or updating records in migration mode.
Object Metadata Service Enhancements
Section link for Object Metadata Service EnhancementsThis feature enhances the SDK Object Metadata Service in the following ways:
- Developers now have the ability to retrieve the join type on an object. The join type can be Simple, Complex, or Undefined (for any objects that are not used as a join object). A potential use case for this feature is writing VQL queries based on the join type of an object.
- Developers now have the ability to retrieve picklist field dependencies on any object picklist fields. A potential use case for this feature is setting picklist field values according to the picklist field dependencies, ensuring the same data integrity that would be enforced for users.
Enhancements to Query Field Type
Section link for Enhancements to Query Field TypeField rules now allow using a different SELECT field than the Query field in the field rule. This will be used by app developers/customers to get required field value without overloading the Query Field.
To achieve this, we’re introducing a new Query Field Select attribute (query_field_select).
The attribute will be recommended on Field Rules used in Vault to Vault Connections, but will not be required for field rules on local or external connections.
Platform MDL
Section link for Platform MDLEnhanced Dashboards Tab
Section link for Enhanced Dashboards TabThe Dashboard component type now includes the tags attribute, which returns a list of tags associated with the Dashboard.
Learn more about Dashboard components.
Reusable Labels for Document Field Layouts
Section link for Reusable Labels for Document Field LayoutsVault will no longer enforce the uniqueness of the label attribute of Docfieldlayout components. Uniqueness will still be enforced on the name.
Learn more about Docfieldlayout components.
Layout Rule: Display As Read-Only Effect
Section link for Layout Rule: Display As Read-Only EffectAdmins can now configure Layout Rules to display fields as read-only. This feature adds a new displayed_as_readonly_fields attribute, which accepts a comma-separated list of field names, to the Layoutrule component.
Learn more about Layoutrule components.
Notification Categories & Email Preferences
Section link for Notification Categories & Email PreferencesAdmins can now specify a notification category for each notification template. Admins can also now define the frequency of notifications Vault sends by email. A frequency of Never treats the notification like an in-app notification only.
The Notificationtemplate component has two new attributes to support this: notification_category and email_preferences.
Learn more about Notificationtemplate compnents.
Application-Specific MDL
Section link for Application-Specific MDLQMS: External Notifications Enhancements: Multiple Recipients and Add Document from Library
Section link for QMS: External Notifications Enhancements: Multiple Recipients and Add Document from LibraryOrganizations often use External Notifications to correspond with stakeholders outside their companies about product complaints through email. This correspondence often involves multiple people identified on a Complaint record, like the initial reporter, the complainant, and healthcare providers.
Prior to this release, users were required to initiate one External Notification for each Person identified on a record. With the 24R1 release, Admins can configure an External Notification that allows users to send one email to multiple Persons on a record.
To support this functionality, this feature adds a new Qualityexternalnotificationtemplate Component Type to all Quality Vaults with QMS enabled.
Learn more about Qualityexternalnotificationtemplate components.
Quality Incidents: Create a Quality Incident from a QR Code (QMS)
Section link for Quality Incidents: Create a Quality Incident from a QR Code (QMS)Veeva QMS enables users to create Quality Incident records that capture information known at the time the incident is encountered, and includes a lightweight process that allows the appropriate individuals to triage the incident and determine if a full-fledged quality event process is necessary. System administrators can now configure QR codes to be printed and placed anywhere employees or contractors work. Veeva QMS users can scan QR codes with their mobile device’s camera to fill out a streamlined page that collects required information about the incident they encountered.
This new feature introduces a new Qualityincidentintakelayout Component Type for MDL.
QMS: Duplicate Check: Check Lifecycle State Processing Enhancement
Section link for QMS: Duplicate Check: Check Lifecycle State Processing EnhancementIn support of new changes to the Record Check: Duplicate Checks feature set, the Qualityrecordcheck component has a new attribute, lifecycle_states_to_not_transition. This optional attribute is only applicable to Duplicate Check types of Record Checks. Setting this attribute to a list of one or more lifecycle states shall prevent instances of the Qualityrecordcheck from performing lifecycle state transitions on matched records in one of those states.
Validation Management: Printable View for Test Scripts
Section link for Validation Management: Printable View for Test ScriptsWith 24R1, Veeva Validation Management will provide a way to generate a printable view of a test script that will include related object records and evidence collected from executors, such as screenshots, that are stored as test step file attachments. With the introduction of printable views, a new Printableviewtestscript component type will be available via MDL. The component references two files as attributes: template (XML) and header_logo (*.png, *.jpg, *.jpeg, *.bmp, *.gif, *.svg, *.tif, *.tiff).