Skip to main content
hamburger menu Created with Sketch.
Veeva Support US Holiday: Jul 3rd - Limited staff, please plan accordingly

Search the Knowledge Base

Engage Connect FAQ: Engage Connect Platforms and Configuration

  • Updated

Engage Connect FAQ: Engage Connect Platforms and Configuration

For ease of reading, we have broken out the Engage Connect FAQs into sub-articles.

This article covers: 

For other topics in the Engage Connect FAQ, please see the sub-articles list on the top level article
FAQs: Engage Connect Functionality and Best Practices in Veeva CRM.

Engage Connect Platforms

What Apps/Platforms Can HCPs use to work with Engage Connect?

HCPs can use Engage Connect through the Engage Web Client (https://app.veevaengage.com) or the Veeva Engage app available for Android and iOS.

 

What Apps/Platforms Can CRM Users (Reps) use to work with Engage Connect?

CRM Users (Reps) have a separate app, named Engage Connect, also available for Android and iOS.
There is no Engage Web Client for CRM Users.

Setting Up the Company Configuration File for Engage Connect

What is the purpose of the Content Tab in the Company Configuration File?

The Content Tab allows admins to define approved text and links to externally-hosted content.
Content can be Header text without a link, or a link to externally hosted content, hosted by the customer on their own website.

 

Are the Links in the Content Tab links to CLM from the CRM Org?

Links in the Content Tab are not links to CLM or Approved Email text hosted in the customer’s CRM Org, and Veeva Engage does not host the content linked to by the link URL. Companies should provide URLs to their own resources that they host outside of CRM and Engage Connect.

 

What is the purpose of the Footer tab in the Company Configuration File?

The Footer Tab enables admins to create footers that display any additional required regulatory or compliance links. Footers display at the bottom of approved content, or beneath the Regulatory Statement on Brand and Rep Profiles.

 

How should the Company Configuration File be handled when moving from Sandbox to Production?

Our documentation on Creating the Company Configuration File states that to create a backup of existing configuration, as well as to create a template for correct data formatting, admins should first export their existing company configuration settings. A file created from a Full Sandbox could then later be used to configure a Production Org. However, the information on the Company Tab would need changed for loading to the Production Org.

There are typically differences in what is set up in Sandbox vs. Production, especially with users, so it is very important to ensure that the data file reflects updates to the right environment. The Company tab is always required and should reflect the correct environment. But if the configuration is done properly in Sandbox, the Sandbox export is a great starting point to create a Production Company Configuration file. Or, data from a Sandbox export could be copied and pasted into the Production file.

Data such as Resources may be uploaded to the Sandbox for testing purposes and not required in Production, or are no longer valid after testing is complete. Even if it is no longer visible in Engage, it would still appear in the exported company configuration file. So customers should be careful about adding unnecessary data into Production.

It is a best practice for customers to export the latest data from any environment and make changes directly in that file. To reduce the risk of unintentional edits, Veeva also recommends that any data that is not being changed is completely removed - i.e. entire tabs should deleted if there are no changes on it and even rows within a tab should be deleted if they aren't being updated.

Please see our Online Help on Best Practices for Importing Company Configuration Files. Here we state:

To reduce the risk of unintentional edits, delete any tabs or rows that are not being edited by the Company Configuration file. The Company tab must always be included.

 

Can customers see which users have imported changes to the Company Configuration File?

There is no direct customer access to the logs of Company Configuration File imports. Customers cannot see this information from within the Engage Connect Administration tab. 

However, Veeva keeps the logs of these imports for 90 days and can research them on a case-by-case basis. Customers should open a case with Veeva Product Support if investigation is needed.

 

Is it possible to automate exporting the latest company configuration file via API? 

This is not currently available within Veeva CRM or Engage Connect.

Customers can export the current state of the Company Configuration File using the Engage Connect Administration Tab.

Test HCPs - Setup and Functionality

What is the Purpose of the Test HCPs Tab in the Company Configuration File? 

The advised way to test HCP functionality in Engage Connect is to create Test HCPs in the Engage Connect Company Configuration File's Test HCPs Tab.

The Test HCPs tab enables admins to create test HCP Engage Connect accounts/users, enabling admins and CRM users to test content and functionality from the HCP’s perspective while maintaining good data quality, for example, when testing Engage in sandboxes.
For testing purposes, customers can create/import a list of Test HCPs that are aligned to their Company, on the Engage Connect Company Configuration File.
These Test HCPs have limited functionality, and allow customers to see and test only THEIR company's Engage Connect environment.

 

What Functional Restrictions do Test HCPs Have?

Test HCPs have additional restrictions so that they can be used solely for testing an individual company's Engage Connect setup.

  • CRM Users (Reps) and Test HCPs can only connect to Test HCPs in the same company.
    • Test HCPs can only connect with Reps from the same Org as the one where they are set up in the Company Configuration File’s Test HCP tab.
    • Test HCPs can only connect with other Test HCPs from that same Company Configuration File.
  • HCPs not set as Test HCPs (i.e., "real HCPs") can't connect to Test HCPs.
  • Test HCPs can't connect to Reps from other companies.

CRM Users (Reps) can connect to ‘real’ HCPs (i.e., HCPs not set up as Test HCPs in a Company Configuration File) from any company. But Reps can only connect to Test HCPs that are associated to their company and set up in the Company Configuration File for their Org, not Test HCPs from other Orgs or companies.

“Real” HCPs – i.e., ones not set up as Test HCPs – cannot connect with Test HCPs, from any company.

 

What Email Address Restrictions do Test HCPs Have?

Test HCPs are aligned to a company by being uploaded to an Org in the Company Configuration File for Engage Connect. Their 'company' is not based on their email domain. This allows customers to use personal email addresses (non-company addresses) like Hotmail or Gmail for Test HCPs.

Engage Connect will not allow Test HCPs to be created with email addresses that are already used by CRM Users/Reps or Admins from within the Org. Customers should use other email addresses for Test HCPs. Again, customers can use outside, non-company addresses from other email providers like Hotmail or Gmail for Test HCPs.

 

Why Does CRM Return an Error Saying the HCP Already Exists when trying to upload Test HCPs?

Engage Connect does not allow an email address to be shared across different types of users (CRM Admins, CRM Users/Reps, and HCPs).

If an email address is already being used by an Org Admin or CRM User in the Org, it cannot be used for a Test HCP.

Customers who attempt to upload a Company Configuration File with a Test HCP that uses an email address already assigned to a User in the Org will get an error stating the HCP already exists. Try using another email address for the Test HCP. Customers can also use an email address outside their corporate email domain, such as Gmail or Hotmail.

Engage Connect Sandbox Refreshes

Why is the Engage Connect Administration Tab showing an error in a Sandbox Org after it has been refreshed and returned to the Veeva Managed Orgs? 

When a Sandbox Org using Engage Connect is refreshed, it must be added to the Veeva Managed Orgs list and to the Engage Sandbox environment with relinked Engage licenses, both under its new post-refresh Org ID. When a Sandbox is refreshed, Customers should open a Support ticket requesting that the refreshed Sandbox Org be returned to the Veeva Managed Orgs list and noting what other tasks are required, such as Engage licenses and Engage Connect. 

 

The Sandbox org's new Org ID must also be added to the Engage Connect database. Org IDs that are new to our Managed Orgs list are loaded into the Engage Connect database weekly, on Monday mornings. Until the Sandbox org's new Org ID is added to the Engage Connect database, customers may see an error on the Engage Connect Administration Tab.

Users may see an error page beginning with: 

Error in context getOrgConfigConnect: error in fetching org config

This is because the Sandbox Org's new Org ID has not been added to the Engage Connect database yet. 

 

Once the Sandbox Org is added back to our Managed Orgs list and the Sandbox Org's new Org ID is loaded from our Managed Orgs list to the Engage Connect database, this error page will be replaced with the normal Engage Connect Administration Tab.

Normally, if a customer encounters this error page after a Sandbox Refresh and after the Org is returned to the Veeva Managed Orgs list, the error should clear up the next Monday morning. However, the Engage Connect Products team can manually add Org IDs to Engage Connect between these weekly loads. If there is a need to have a refreshed Sandbox re-added to Engage Connect sooner than the next Monday morning, please note that in the Support ticket for the Sandbox post-refresh and Managed Orgs List tasks.

 

Sandbox Users and Engage Connect Groups

In a Sandbox org, user email addresses are automatically appended with .invalid at the time of org refresh. 

As noted in our Online Help, users cannot be added to Engage Connect groups if their email address ends in .invalid. Please correct Sandbox user email addresses after Org refresh before adding them to Engage Connect Groups. 

Data Loading Engage Connect Groups

New Engage Connect Groups can be data loaded to Veeva CRM, and Engage Connect Group provisioning requests can be data loaded to user records. 

For information on this process, please see our Online Help page Data-Loading Engage Connect Groups.

The following is meant as additional reference information for Data Loading Engage Connect Groups.

 

The Customer Key field is meant for customers to identify Engage Connect Groups in systems outside Engage Connect, and can be populated with values of customers' choice. This allows customers to mark Engage Connect Groups with their own unique identifier to better correlate with their own systems. 

 

Data loading Engage Connect Groups creates an Engage Connect Group Request record. 

Engage Connect Group Request records are not created when a group is created manually in the Engage Connect Administration Tab. Additionally, Engage Connect Group Request records are not updated when changes are made to an Engage Connect Group manually in the Administration tab.

The Engage Connect Group Request object is a transactional object meant for creating or updating Engage Groups by data loading. Engage Connect Group Request records are not meant as a full record of all groups created or modified in an Org, as Groups can be created or modified through the Engage Connect Administration tab. The download of the Company Configuration File will always show the most up-to-date values for Engage Connect Groups.

 

Engage Connect Group Request records will show an External ID for groups created by this data loading process.

At this time, the External ID for groups created manually through the Engage Connect Administration Tab is not exposed for customers. If you need to data load changes to a Group that was created manually, please open a CRM Support ticket asking for the External ID of the Group(s) in question.

Updates to manually created Groups can be made via data loading as long as the External ID is included in the External_ID_vod__c field of the upload file.

 

Related Documentation:

CRM Help Documentation: 

Knowledge Base:

 

Powered by Zendesk