Modify workflow settings

Administrators can use these settings to change the default behavior for add A request to add a new HCP or HCO profile to a customer instance. Add requests are matched against existing data before routing to customer data stewards for review. and change requests A request to change data from Veeva CRM, the Network API, or from within the Network user interface. Change requests are processed by either customer or Veeva data stewards, depending on ownership of the data being changed. . Behavior you can change includes automatically approving requests, forwarding rejected records to local Data Stewards for review, and creating unverified records.

The following diagrams outline the workflow for add and change requests.

Add request workflow

Change request workflow

Modify workflow settings

To modify workflow settings, in the Admin console, click Settings > Workflow Settings.

General workflow settings

In this section, you can modify the following behavior:

• Strong match: Determines whether an add request goes through or bypasses strong matching when creating an unverified record. You can bypass a strong match to immediately create an unverified record so the Veeva ID can be used by the calling application.

  About strong matching

  Strong matching helps to minimize the creation of duplicate records in Network. Strong match uses the Add Request match configuration. If profile validation rules are enabled, the rules run on the change request for the merged records, not the initial add request. For more information about profile validation rule behavior for merged records, see Records for data validation.

  • When Strong Match is enabled together with Create Unverified, an unverified record will be created if the add request does not match with an existing record.

  • When the Create Unverified, Strong Match, and Review Rejections options are all enabled, for example, only ACT A high confidence match between two records. ACT matches result in a merge without any human review. matches are performed in your Network instance, and no suspect match tasks are created. However, the created record could trigger a suspect match The identification of multiple records that are suspected to be duplicates of one another, but without high enough confidence for automatic resolution. task in Veeva OpenData.

  • When the Review Rejections option is enabled, both ASK and ACT matches are performed if the request is rejected by Veeva OpenData.

• Create Unverified: Immediately create records (in an unverified state) when new HCPs or HCOs are submitted as requests in your Network instance. Once the record has been approved, the record state is updated. You can also perform searches on unverified records. Suspect matches are not supported for unverified records.

  This setting must be enabled for users to make changes to unverified records; otherwise, change requests are automatically rejected. For more information, see Queued DCR tasks.

  For details about creating unverified records through the Network API, see Reserved Network entity ID.

  Parent HCO handling in unverified records

  In situations where an unverified HCP has a parent HCO that is also unverified, the workflow will queue and release the related HCP task only after the unverified parent HCO has been processed.

• Skip Address Verification: Determines if address cleansing takes place. If it is enabled, no verification occurs on addresses. When Skip Address Verification is enabled, change request match rules must be updated by a Network Support representative.
• Send Add Request to Local Stewards when parent HCO is customer owned: Route add requests to local Data Stewards when the request includes a customer-owned parent HCO relationship.

Overwrite sub-object comparison

In change requests, new sub-objects are compared to existing objects in order to avoid duplication. By default, the status of these objects is ignored, which means active sub-objects can be considered a match to an inactive sub-object when other fields within the records also match.

For example, inactive addresses are not visible to end users (sales reps) on records. When a user submits a new address and it matches to an existing inactive address, it results in a change request for the inactive address instead of creating a new under review A record that has not yet been validated by a data steward. address.

To avoid matching between an active and inactive sub-objects, set the Overwrite Sub-Object Comparison workflow settings to include the status in the match comparison.

In the Overwrite Sub-Object Comparison setting, choose one of the options for each sub-object:

• Include Status - Consider the object’s status during match.
• Exclude Status - Ignore the object’s status during match.

  

To understand how sub-objects are compared to identify duplicates, see Duplicate detection rules.

Veeva CRM considerations

When Create Unverified is enabled, the Include Status matching option for addresses should also be enabled to ensure that active unverified addresses are created in Network and function properly with Veeva CRM.

Veeva CRM addresses can remain in Staging status when new addresses are sent to Network for validation in a data change request. This happens when an unverified address, created in CRM, matches an existing address in Network but is not assigned a Network ID (VID). This may cause duplicate addresses in CRM.

Allow attachments on Add Request and Change Request submissions

Enable users to add attachments to data change requests. For details see, Enable attachments for DCRs.

Auto-approve add requests

Define the criteria for automatically approving new customer-owned records. These settings apply to Veeva standard objects and custom objects.

By default, all add requests for customer-owned records are sent to your local Data Stewards to process. You can change this default behavior to have all or some requests automatically approved.

Main objects

Choose one of the options for each main object:

• All Add Requests will be sent to the local inbox for review - Requests will be sent to your local Data Stewards to process. This is the default behavior.

• All Add Requests will be automatically approved by the system - Requests will be approved by Network.

• Configure which Add Requests will be automatically approved by the system - Add requests that include the field and value criteria that you define will be automatically approved. If you select this option, choose any reference type field, including Boolean references, for the criteria. If you include multiple fields and criteria for each object, each field is treated as an OR condition.

Sub-Objects

Specify the sub-object and relationship objects that should be auto-approved on add requests.

This applies to all sub-objects or relationship objects of that type regardless of the related main object. For example, if you add the Address object to the Sub-Objects section, addresses for any main object (HCP, HCO, or any custom main objects) will be auto-approved on add requests for customer-owned records.

Supported scenarios

Auto approve applies to the following:

• Veeva OpenData records if Review Rejections is enabled and the add requests meet those settings.

• Customer-owned records when using custom reference codes for HCP or HCO types.
• New sub-objects on customer-owned records.
• New records for which the primary country is not a Veeva OpenData country.

See Sample scenarios for related examples using this setting.

Auto-approve change requests

Define the criteria for automatically approving changes on valid customer-owned records.

By default, all change requests for customer-owned records are sent to your local Data Stewards to process. You can change this default behavior to have all or some requests automatically approved.

Note: These auto-approve settings apply to Valid records (record_state__v = Valid). Change procedures can be set for individual customer managed fields on unverified records (record_state__v = Under_Review).. Change procedures on individual fields override these workflow settings.

Main objects

Choose one of the options for each main object:

• Change Requests will be sent to the local inbox for review - Requests will be sent to your local Data Stewards to process. This is the default behavior.

• Change Requests will be automatically approved by the system - Requests will be approved by Network.

• Change Requests will be automatically approved by the system - Change requests for a record where the current field and value meet the criteria that you define will be automatically approved.

  Note: The behavior for this option is different for add request and change requests

  If the defined criteria field is included in the change request or is changed by the change request (regardless of the field value) the change request will be sent to local Data Stewards.

  Example

  On the HCP object, set the criteria to auto-approve change requests when the HCP Type field has the value Dentist.

  

  When a change request is submitted for a record where the current value of the HCP Type field is Dentist, the change request will be automatically approved. For example, if you submit a change request to modify Dr. Chang's address, the change request will be automatically approved.

  

  However, if the change request contains the HCP Type field itself, regardless of the value, the change request will be sent to local Data Stewards for review. For example, if you change the HCP Type from Dentist to Business Professional, or even if the HCP Type value on the change request is the same as the existing value (Dentist), the change request will be sent to your local Data Stewards.

Review master data provider rejection of add requests

By default, all add requests that are rejected by Veeva OpenData and third party data providers are discarded. You can change this default behavior to have all or some rejected add requests routed to your local Data Stewards for review.

This applies to Veeva standard objects only.

Choose one of the options for HCPs and HCO objects:

• All rejections by master data providers will be discarded - This is the default behavior.

• All rejections by master data providers will be sent to the local inbox for review - Rejected add requests will be routed to your local Data Stewards to review and will become local records if accepted.

• Configure which master data providers rejections will be sent to your inbox for review - Only the add requests that meet the criteria that you define will be routed to local Data Stewards. If you select this option, choose any reference type field, including Boolean references, for the criteria. If you include multiple fields and criteria for each object, each field is treated as an OR condition.

Local Data Stewards will only see the rejected task in their inbox if the add request was initiated by a non-Data Steward user. If the add request was initiated by a local Data Steward or System and Data Admin, Network automatically approves the record.

See Sample scenarios for related examples using this setting.

Default values for new objects

You can define default field values to be automatically added when new object requests are submitted without a value. When an add request is submitted without values for these fields, the default value is added as soon as the task is created.

Prevent duplicate records

Adding default values here can prevent duplicate records from being created.

Default value - data model

When a new object is submitted without a field value, the default value defined in the field configuration (Data Model) is applied, if available, when the task is approved. It does not display when Data Stewards are processing the request and it is not used for matching, so a duplicate record could be created.

Default value - workflow setting

Using this workflow setting, the default value is applied when the task is created, so it is used during matching. Data stewards can override the field value when they process the task .

Support for this setting

• New records - Default values are applied to new records or new sub-objects on existing records. If the new record or object is matched to an existing record, the value remains on the change request.

• Requests created - This supports add requests that are submitted through the Network UI and API and through Veeva CRM using the Network Bridge.

• Objects - Default values can be applied to Veeva objects. If a custom sub-object exists on a standard object (for example, a new HCP), the default value can be applied to the sub-object.

• Fields - The default value is applied only when the field does not contain a value. Only reference type fields are supported.

• Stewardship - Default values are applied to data change requests that are sent to local data stewards or Veeva OpenData stewards. However, default values that are custom reference values are not sent to OpenData.

Adding default values

To add a default value:

1. Click Add Field.

2. Expand the list in the Field column and choose the object and field. Only reference type values are supported.

3. Expand the field in the Value column to define the default value.

4. Save your changes.

When a DCR is created for a new object, the workflow will populate the field with this default value if a value was not provided.

Routing of add requests for addresses, licenses, and parent HCOs

Define routing rules so add requests for sub-objects are routed directly to local Data Stewards even if the object is owned by Veeva OpenData or a third party data provider. Use this setting to locally manage specific sub-objects. For example, if you've defined a custom address type that you want to manage locally, you can create a rule so add requests for addresses with that address type are routed to local Data Stewards.

Important: If you create a sub-object exception routing rule, contact Veeva Support to update your sub-object comparison rules. These rules are not visible in the Network UI. Do not use sub-object routing for addresses and parent HCOs in countries where the Network Address Inheritance feature is enabled.

Add request routing options

There are two options for each Veeva standard sub-object (addresses, licenses, and parent HCOs):

• Default routing rules - This option is selected by default.

  When add requests are submitted, the following behavior occurs depending on the record owner:

  • Veeva OpenData records - Add requests are sent to OpenData Data Stewards.
  • Third party master records - Add requests are sent to third party master Data Stewards.

  If add requests are accepted by master Data Stewards, the sub-object is created and a data change request (DCR) is routed to local Data Stewards to process any custom fields.

  If the add request is rejected, the DCR is routed to local Data Stewards if the review rejection setting was enabled.

  • Locally managed records - Add requests are sent to local Data Stewards

• Configure exception routing rules - Override the default behavior and send add requests for specific sub-object types to local Data Stewards.

  If you choose to create a rule, complete the following steps:

  1. In the Field list, choose the field for the sub-object. For example, in the Address section, choose Address Type.

  2. In the Value list, select values for the type field. For example, choose the Ship To custom reference value.

  Note: Rules can only be defined for standard fields with custom reference values and for custom fields that use standard and custom reference values.

  Exception routing considerations

  • If the add request is for a new OpenData or third party record, the DCR is first sent master Data Stewards for processing and then the sub-object is routed to local Data Stewards.

  • If an add request for a master record is rejected, the sub-object record state is updated to Invalid and the sub-object will not be routed to local Data Stewards. If review rejections is enabled, the add request is routed to local Data Stewards, as usual, regardless of the sub-object type and exception routing.

Creating country exceptions

You can create exceptions to the specified workflow settings by country. To add an exception, click the + icon to the right of the Exceptions section on the Workflow Settings page.

In the Countries field, begin typing or click and select a country from the list. You can include more than one country in this field.

Update the general workflow settings and auto-approve and review rejection behavior as before, and click Save.

Sample scenarios

The following scenarios illustrate possible outcomes for specific workflow settings. Note that based on user type, the following applies to records rejected by Veeva OpenData:

• Requests made by Data Stewards or Data Managers are automatically approved.
• Requests made by Administrators or Standard users are routed to your local inbox as tasks for Data Stewards to review.

Scenario 1

The following workflow settings are configured:

• Review Rejections - Set to Review for all HCP and HCO types.
• Auto Approve - Any of the options are set for add requests.

A Data Steward adds a new HCP (prescriber) in a customer instance. The result is as follows:

• Veeva OpenData rejects the add request.
• The request is automatically approved in your customer instance as a local record because a Data Steward submitted the add request.

Scenario 2

The following workflow settings are configured:

• Review Rejections - Set to Review for all HCP and HCO types
• Auto Approve - Set to OFF for new records

A Standard user adds a new HCP (prescriber) in a customer instance. The result is as follows:

• Veeva OpenData rejects the add request.
• Because the request was created by a Standard user with auto approve off, a task is routed to the local inbox for Data Stewards to action.

Scenario 3

The following workflow settings are configured:

• Review Rejections - Set to Review for all HCP and HCO types
• Auto Approve- Set to ON for new records

A Standard user adds a new HCP (prescriber) in a customer instance. The result is as follows:

• Veeva OpenData rejects the add request.
• Because auto approve is on, the request is automatically approved in the customer instance as a local record.