Troubleshooting Network widgets
These sections describe potential issues that can occur when you are creating and configuring Network widgets.
Widget issues
The following sections describe key areas and issues that may require additional planning and configuration to ensure smooth operation of your Network widgets.
Before investigating more complex issues and solutions, ensure that your Network widget is enabled.
Widget domain setting
If the domain in your Network widget configuration is too specific, access to the widget may be denied.
When you configure your widget in Network, ensure that you have specified all domains that require access to the widget. You can click the + Add Domain link to add as many domains as necessary.
Conversely, if your domain setting is too broad (for example, *), your widget may be exposed to unwanted access. You should check these settings throughout configuration (and beyond, as web application domains may change) to ensure that the domain is masked appropriately.
Blank widgets
In rare integrations, the widget panel may appear empty, and the widget doesn't load. The browser console may indicate that there are issues with missing dependencies or duplicate elements.
In these instances, your web developer may need to embed the widget in an iframe element in the application code. In addition, a few functions and event listeners are required for the embedded widget to work properly.
More information, along with code samples, is available on the Veeva Network developer site at https://developer.veevanetwork.com/widgets/.
DCR routing
If you experience unexpected results when DCRs are submitted by a widget, check to ensure that the system used for the Network configuration is not proprietary, restricted or third party.
With no restrictions, you can help ensure that DCRs generated by associated widgets will not be automatically rejected.
Embedding widget code
When Network administrators generate, select, and copy code to send to the web developer, it's important to ensure that the code remains intact, with no changes to elements or values within the code.
Values such as the widget-id contain numbers and mixed-case letters that need to be preserved when pasted into the web application the developer.
As with other settings within the Network configuration pages for widgets, assume that all values are case sensitive.
Security issues
The following sections describe some of the key areas to verify as you complete configuration for single sign-on within your Network instance and on your identity provider administration pages. Minor discrepancies in any of these settings can cause authentication to fail and prohibit widgets from loading.
Before investigating more complex issues and solutions, ensure that security policies are .
SAML security policy settings
Ensure that the SAML security policy is properly configured in your Network instance.
When you add Network as an application in your identity provider's administration pages, the URLs you specify or that are generated on that site must exactly match those in the SAML settings in Network:
- Issuer (URL)
- Identity Provider Login URL
- Network SSO Login URL
Note: When you configure these settings on your identity provider's site and in Network, treat all values are case-sensitive.
When you configure a Network application on your IdP's site, an identity provider certificate is created. You must upload that file on this page.
Field mappings
The Mapping section of the Single Sign-On Settings page enables you to map SAML attributes to the corresponding Veeva attributes. The fields specified here must match those specified when you configured the Network application on your identity provider's site. All values except mail are required.
In the configuration for your identity provider, the SAML attributes are specified along with the values recognized by the identity provider; for example, in an Okta configuration, the value for uid is user.login.
Without these attributes defined and mapped on the IdP site and in Network, authentication will fail. These are required for single sign-on configuration with Network.
Country and data visibility mapping
The country attribute passed by the single sign-on settings maps to the country specified in the Country and Data Visibility Profile Mapping section. A country must be provided for the configuration to work properly.
Authentication exceptions
In some cases, an exception may occur during single sign-on, resulting in a 404 error in the browser. The following are a few areas to check when troubleshooting this issue.
Missing country in IdP configuration
A missing country value in the identity provider configuration for the user can cause an exception during authentication.
If this occurs, edit the user's profile on the identity provider site and ensure that a country code (for example, US) is provided for the user's country setting.
Missing or unassigned SSO security policy
If no single sign-on security policy exists, or has not been assigned to the user experiencing authentication issues, an exception can occur during login.
If this occurs, ensure that a policy exists in Network and that its Authentication Type field is set to Single Sign-on with SAML.
Any users that will require single sign-on access will need to be assigned this profile. In the user's profile, this is done in the Settings section, in the Security Policy drop-down list.
