Click a point on the timeline to view features released in that version.
New Profile Support
Data Privacy Opt-Out
Delete Locally Managed Records
Reference Data Formatting
Network Search Widget
Using the search widget, business users can search for and view real-time master data from your external application without logging directly into the Network instance.
For example, call center representatives can search and download HCPs within Network and Veeva OpenData without leaving the application they are currently in, or sales reps can search for and attach an HCP's record to an expense or event.
Reference Data Version
A new version, V7.0, is now available for reference data exports in target subscriptions.
If administrators or data managers choose to export reference data and select V7.0, the exported .csv file will include target alias codes and names.
The new reference data version is available in all Network instances by default.
Customers can now enrich addresses in Germany by adding cluster codes.
In this release, Network has included support for the following third party cluster provider / country combination:
Germany - IQVIA™A TPA must be signed with the third party cluster provider to use the cluster management feature.
The redesigned Profile page has been updated to include several usability enhancements to enable users to quickly find and access record information.
Veeva OpenData recordsWhen users access a record owned by Veeva OpenData that hasn't been downloaded to their Network instance, only populated fields display. To download the record, click Download from OpenData at the top of the page.Hide empty data fields
Users can choose to hide fields on the record that do not contain data; empty fields display by default.Record options
As users scroll through the record, the actions available from the summary header move into the Options menu.Field ownership highlighting
Users can differentiate field ownership by the colors of the field names: customer-owned (gray or green), Veeva OpenData owned (orange), and third party owned (blue).
Extended fields on addresses
On each expanded address card, a new option, Extended info, enables users to view all of the cleansed address fields that are included in the profile layout.
Tooltips on badges
On child object summary cards, tooltips have been added to some badges to provide more information for users.
Differentiating between expiring and expired licenses is now easier because the expiring licenses text has been changed to "effective until ".
Inactive custom keys
Users can now differentiate between active and inactive custom keys because summary cards have a badge that indicates inactive status.
Data stewards and data managers can more efficiently process suspect matches.
The data validation pane has been updated so it displays more prominently on the redesigned profile.
The Add New Profile page has been redesigned so that it's consistent with the redesigned profile page.
US addresses can be reconstructed to ensure that they are standardized to support requirements for downstream systems.
Most downstream systems map Address Line 1 only and expect it to contain the street name and number. However, address cleansing places the building or organization name in the first few address lines and moves street number, name, and suite number to the last available address line.
If this information is removed in downstream systems, samples cannot be delivered. Additional costs and IT overhead might be incurred to resolve the problem.
Using this feature to normalize the address lines will support downstream systems and improve data consistency.
This feature is not enabled by default. It applies only to US addresses. To add this feature to your Network instance, contact Veeva Support.
Network users with access to advanced ad hoc queries can now report on comments in DCRs. This is particularly helpful for teams so that they can verify data quality by validating the correctness of the data based on the comments that have been added to the DCR.
This enhancement is available by default. DCR comments will be tracked for reports from version 18R1.1 and onwards; comments added to DCRs prior to this release are not available in reports.
To report on DCR comments, use the change_request_comment table in your advanced SQL query.
Reporting on DCR Comments
Data model fields that have been disabled in an instance are now masked in advanced ad hoc query results. Previously, disabled fields were unavailable to report on from the Network UI, but if users typed an advanced SQL query, data could still be retrieved for those fields.
This enhancement is enabled by default.Disabled fields
Administrators and data managers can disable fields in the Network Data Model. Before a field, or a set of fields (for example, HCO_focus_area__v fields), is disabled, users are reminded that the field data will become unavailable.
When the field is disabled in the Network Data model, the data is immediately masked in reports; it is not dependent on the reporting database updates.
If users write an advanced SQL query containing a disabled field, NULL is the only value returned for the field; every value is replaced with NULL when the query is executing.
Masking Disabled Fields
Grouped fields are now available consistently within Network features. Some Network data model fields are grouped within a set; for example, Specialty, Phones, Focus Areas, and so on. In Network features where you can filter or search for data within fields, it's useful to work with the fields as a group instead of having to choose individual fields.
For example, if users are searching for HCPs that specialize in stroke medicine, they can select the All Focus Areas group of fields so Network searches the 36 fields in that set:
(hcp_focus_area_1__v to hcp_focus_area_36__v).
This enhancement is enabled by default
in all Network instances. It applies to all
standard (__v) fields that are part of a set
in the Network data model:
Data validation rulesAdvanced searchAd hoc queriesVOD Subscriptions
(All Specialties only)Target subscriptionsSearch API
The profile widget enables business users to view real-time data from an internal web-based application without logging directly into the Network instance. For example, field and marketing users can view an HCP profile and validate address information or parent affiliations for event or marketing material.
Network’s profile widget code provides the following for easy integration:User interface for viewing profiles.Integration with the Network APIs for
displaying profiles from your Network
instance.Ongoing maintenance to support new
features and data model changes.This feature is not enabled by default. For more
information, contact Veeva Support.
Bulgaria has been added to the list of opted-out countries in the Veeva OpenData EUMaster. Records that are opted-out by Veeva OpenData do not display and cannot be accessed in downstream systems. This ensures data privacy for opted-out HCPs to satisfy regional regulatory requirements.
Features have been added in this release to helps customers comply with the European General Data Protection Regulation (GDPR). These features enable you to support requests from HCPs to remove their personal data and to remove records for data storage period limitations.
Using these features, you can delete locally managed HCO and HCP records and anonymize HCP records so that personally identifiable data is removed. They are also useful for removing records from your Network instance that are no longer being updated.
The following data maintenance jobs have been introduced in this release:
Delete locally managed records - HCP and HCO records can have their record state set to Deleted. The records will not be searchable in your Network instance, but the data can still be accessed through reporting and tasks.
Anonymize HCP records - HCP records (managed locally or by Veeva OpenData) that have a record state of Deleted can be anonymized so that all personal data is completely removed from the record. An anonymized record is completely inaccessible in the Network instance. If the record is exported to downstream systems, only the record information (created date, Network entity ID, and so on) can be viewed. Use the features together to process HCP records for GDPR compliance.
Administrators and data managers can now delete locally managed records in Network using a data maintenance job.
Deleting records is important for complying to GDPR requirements around data retention periods and the ability to remove personal data for HCPs, if requested. It is also helpful for removing locally managed records from your Network instance that are no longer being updated or are no longer useful; for example, candidate records. When records are deleted, the record state (record_state__v) for the HCP or HCO and its associated child objects is set to Deleted. Users can no longer access the record using Network search.
Deleting locally managed records
cannot be reversed.
This feature is available by default,
but administrators must enable the
feature in their Network instance.
Administrators and data managers can now create data maintenance jobs to anonymize deleted HCP records. This feature helps customers comply with the European General Data Protection Regulation (GDPR) by supporting requests from HCPs to remove their data and to remove records that exceed data storage period limitations.
When deleted HCP records are anonymized, all of the personal data is masked or blanked out and access to the record is further restricted in the Network instance. If records are exported to downstream systems, only record information and data that is not personally identifiable (created date, last modified date, VID, record state, and so on) can be viewed.
When a deleted HCP has been
anonymized, users can no longer
access the record in their
This feature is available, by
default, but administrators must
enable the feature in their
New API calls have been introduced so that suspect match tasks can be created and retrieved through customer web portals.
Batch Create Suspect Match - create multiple suspect matches through the API
Batch Retrieve Suspect Match - obtain information about multiple suspect matches through the API
Some customers have web portals that enable HCPs to log in to find information about products, events, and so on. If HCPs find duplicate records of themselves, they can now request that the records be merged by submitting a suspect match task using the Network entity IDs of the records.
This feature is enabled by default.
Network can now reformat reference codes from incoming sources so that all values display in the same case (upper, lower, or mixed case) that is used by reference codes in Network. Previously, reference values from incoming sources displayed just as they were defined in the source, so the cases were inconsistent and looked incorrect.
For example, Network's reference code US-NY is used in the administrative_area__ v field for addresses. The code is used to represent the US state of New York. An incoming source could have records that use the codes US-ny, or us-ny. All of these variations are considered the same by Network because reference codes are case insensitive, but visually they look incorrect. Using this reformatting option, incoming source values are identically aligned to the case used by the reference code in Network, which could be upper, lower, or mixed case.
All new Network instances will have this option enabled by default. For existing customers, contact Veeva Support to add this enhancement to your Network instance. This is an instance-wide setting that will align all reference codes.
click the image to close it
The General Settings page has been redesigned so that administrators can more easily find and update settings for their Network instance:Sections have been added so
administrators can easily scan
the page and find the related
settings.The Edit button has been moved
to the top of the page.
Formatted addresses are now calculated consistently for all addresses. When an address is added or updated through a DCR, using the profile page, or through a source subscription, the formatted address is calculated using address lines 1 and 2 (if available).
This enhancement is enabled by default and applies to all countries except for Japan.
To ensure that all formatted addresses are consistent, when the address verification status is V (Verified) or A (Ambiguous) or P (Partially Verified), both address line 1 and 2 are used to create the formatted address.
This format applies whether the address lines construction feature is enabled or not.
When users select a primary country the selection will now be saved.
This enables users who are always working in a specific country, or are working on a country-specific project, to avoid having to select the country repeatedly each time they access advanced search.
The primary country is saved when users navigate to other pages and when they log out and return to their Network application.
Administrators can now set an option so that it is mandatory that all data change requests (DCRs) have a resolution note. Previously, only rejected DCRs required a resolution note.If you require that all DCRs contain a resolution note, enabling this feature will ensure that data stewards are reminded to add one. An error message displays if data stewards or data managers try to resolve a DCR that does not include a resolution note. This option is available in all Network instances.Administrators must select the Require Resolution Notes option on the General Settings page to enable the feature for their Network instance.
Administrators and data managers can now create and manage profile layouts in the Network user interface. Previously, profile layout configurations were completed using JSON files and APIs, which was time-consuming and error prone. The feature includes a preview so administrators can visualize their changes while they are updating a layout. This feature is available by default. Administrators must enable the feature for their Network instance by selecting the Profile Layout Configuration option on the General Settings page.
Hover over a profile layout to display the Action list . The actions available for a profile layout depend on which type it is. Standard profile layouts - Default layouts that are provided in all Network instances. They cannot be edited. A lock icon displays beside standard layouts. Custom profile layouts - Layouts that have been created in your Network instance for your own use.Actions for profile layouts include:Edit Layout (custom only) - Edit the layout to manage the sections and fields and configure how they display in the profile layout.View Layout - View the layout in read-only mode. Within the layout view, users can preview the layout by searching for an existing entity.Rename Layout (custom only) - Update the name of an existing profile layout.Preview Layout - Search for an entity and view the existing profile layout. The layout can be previewed in either the classic profile or new profile view.Clone Layout - Create a new profile layout by making a copy of an existing layout.Delete Layout (custom only) - Remove the profile layout from your Network instance. Only administrators can delete layouts.
Profile Layout Actions
US addresses can be reconstructed to ensure that they support downstream systems by containing the street name and number.
Now, addresses for Canada are also supported for this feature. Veeva OpenData will also reconstruct address lines for Canada.
This feature is not enabled by default. To add this feature to your Network instance, contact Veeva Support.
Address Line Construction
Network now properly adjusts for daylight saving time (DST) in schedules. Previously, the time did not adjust, which affected subscription jobs because they were running an hour later than the time shown in the schedule.
This enhancement is enabled by default in all Network instances.
When administrators or data managers schedule new subscriptions of any kind (source, target, data maintenance job, and so on), the scheduled time will reflect their current time zone. If they are in a geography with DST, the time shown in the Network UI for the configured schedule will adjust and reflect DST. This also applies if a new schedule is added to an existing subscription.
Existing schedules in existing subscriptions will not be automatically updated. However, if the existing schedule in a subscription is updated in any way and then saved, the schedule will update to adjust for DST from that point onwards.
Usability enhancements have been added to the data change request page to help data stewards and data managers process tasks more efficiently.
Using Tab and hot keys
Data stewards can use the Tab key on their keyboard to move through the fields on the DCR. The first row of the DCR is highlighted by default.
Pressing the Tab key highlights the next row.Pressing Shift + Tab moves to the previous row.When a row is highlighted, using specific keyboard letters toggle the user to the appropriate action button:
A - AcceptR - RejectE - EditIf the field that is being edited is a text field or a drop down list, the field is focused so that users can type or select a value.
Usability enhancements have been made to drop down lists so they remain open allowing users to easily make multiple selections.
Previously, lists would close after a selection was made, so users would have to open it again to make another selection.
This enhancement is enabled by default in all Network instances. It affects filter lists on the following pages in the Network UI:
Data Visibility Profile pageData Validation Rules pageReportsNetwork ExplorerVeeva OpenData Subscriptions
Saved job schedules now accurately reflect the timezone of your own web browser.
Previously, when schedules were saved, the time that displayed was based on the browser time of the user that created the schedule.
The timezone does not display in the schedule.
Suspect match tasks indicate match aliases and filters when they are used by the match process. Aliases and filters are used to improve matching outcomes by making the data more consistent during the matching process. Suspect match tasks display any data that was adjusted by aliases and filters so data stewards can understand why the records were considered a match.
Latitude and longitude fields are now populated and persisted for Canadian (CA) and Australian (AU) addresses after an address is cleansed in Network. Previously, geocodes for addresses only in the United States (US) and France (FR) were persisted.
Geocodes can be used in downstream systems to assist your business processes: for example, event planning and sales performance. You can use the data, for example, to visualize the following on a map:
HCP locations - Use the data to understand where HCPs practice within proximity to a organization when setting up events.Sales data on individual geocoded HCPs - Use the data to compare it against sales data tied to a territory to identify where sales are under performing.Coverage across regions - Use the data to align sales reps accordingly.This enhancement is enabled by default for CA and AU addresses when address cleansing is enabled in your Network instance. These values will display on address records after they are loaded, or after they have been updated.
The number of HCP records that can be included in the .csv file for the anonymize records job has been extended to 60,000. Previously, the limit was 5,000 HCP records.
Search logs provide more information for administrators. The new log data will help administrators understand the users and the information they’re searching for:
Search user name - the user name of the end user performing the search. The Network user name appears for API-originated searches.
Search origin - where the search occurred. The value for this field might be Search Bar, Advanced Search, CRM Online, and so on.
Address query - the address details entered by a field rep during Network Account Search on all platforms.
Data stewards can now add images to comments in data change requests. This enables them to provide evidence for how the DCR was validated; for example, a screenshot of the website where they verified the data.
The ability to provide images enables the users who submitted the DCR to understand the data steward's decision through the attached evidence, especially when DCRs are rejected. It is also helpful when further research is required for the DCR; data stewards can easily find the validation source again using an attached image. This enhancement is available by default. Administrators must enable it for their Network instance by selecting the DCR Comment Attachments option in the General Settings.Image requirements are as follows:.jpg and .png formats are supportedany file size can be uploaded, but large files
are sized down to 1MB automaticallythree images can be added to a comment; any
number of comments can be added to a DCR
Viewing Images in DCRs
When images are added to DCR comments, they display as
thumbnails below the comment. Data stewards can select a
thumbnail to view the enlarged image. If there are multiple
images, click the arrows to browse through the images.
Task Audit HistoryIf a DCR includes images, the attachment count is indicated below the comment in the Message column of the log.
The redesigned profile page is available for viewing and editing on all EU country profiles and Canada. Users can access the new profile by clicking the Try our new view! red ribbon at the top of the classic profile page. Network retains your choice to view the redesigned profile as you view other records and even when you log out and back into the application.To return to the classic profile, click Back to Classic View at the top of the new profile page.
Network Address InheritanceIf Network address inheritance is enabled in your Network instance, address summary cards display a badge indicating address inheritance status.
This enables users to compare addresses by the Network address inheritance status.
Send to OpenDataThe new profile is updated with the Send to OpenData button. Customer data stewards and data managers can send locally managed records to Veeva OpenData as add requests so OpenData takes ownership of the record. This feature reduces stewardship costs for customers and improves data quality.
The active button only displays on records that have a valid record state.
New Profile Features
Administrators and data managers can now use conditional matching in the basic match UI. Previously, conditional matching could only be used in Advanced mode.
This enhancement is enabled by default. It applies to all features where match configurations can be managed:
Ad Hoc Match ConfigurationMatch Default ConfigurationSource Subscriptions
DCRs for Parent HCOs
The Parent Affiliation column in the inbox now indicates if there are any change requests on the parent HCO on the HCP DCR.
This enables data stewards to filter tasks more efficiently by grouping related DCRs by the same parent HCOs. It is also helpful when HCPs have multiple parent HCOs because the Parent Affiliation column displays either the change request value or the primary affiliation.
The parent affiliation DCR value now displays in the inbox regardless of which keyword filters have been applied, so data stewards know which parent HCO to call to validate the HCP change request.