Using VMobile Object Configurations

VMobile Object Configurations (VMOCs) control which objects and records are synced to offline platforms. VMOCs consist of the following main components:

  • Object
  • Device
  • Type
  • WHERE clause

Admins can activate or create VMOCs from the Business Admin view in Vault, or by creating a tab for the vmobile_object_configuration__v object

Ensure all users have at least read permission to the vmobile_object_configuration__v object and at least read permission for all fields on the object, including the modified_date__v and application_profile__v fields. This allows incremental sync to function correctly.

Attachments

The Include Attachments check box on each VMOC controls whether or not attachments for the object sync down to the device along with the records. Ensure attachments are allowed on the object by selecting the Allow Attachments check box in the Options list in the object details.

Deleting and uploading attachments on mobile platforms is not supported.

See Managing Attachments Offline for more information.

Device

Each VMOC is mobile device-specific. For each object to sync down to mobile platforms, an active VMOC must exist for the relevant device__v field.

Types of VMOCs

Full Object Sync

Full Object Sync syncs all of the data contained within an object to Vault CRM Mobile platforms. This type of sync entry is reserved for reference objects, for example, the Product Catalog and other lookup objects.

Top Level Sync

Top Level Object Sync is reserved for master objects in Vault CRM, including Account, Medical Event, and User. The Include Related Objects check box enables the sync process to examine the user's layout for the object and identifies all objects in Related Lists. Any that do not already have a VMOC entry are added to the query and treated as top level objects.

The WHERE clause does not filter for those related objects, other than standard visibility of the parent record. The parent's WHERE clause will not filter these objects. This is particularly suited for parent objects with private sharing or similar built-in visibility constraints.

The following objects are typically synced using the Top Level Object Sync setting:

  • call2__v
  • user__sys
  • product_metrics__v
  • account_plan__v
  • address__v
  • tsf__v
  • medical_event__v

Related to Top Level Sync

VMOCs of this type are queried as sub-queries of the specified parent top level object. Records for this object only sync if they are associated with a parent record that is also synced. VMOCs of this type can also have their own WHERE clauses to further filter records synced.

Child and Parent Row Sync

Used when a child object controls the visibility of the parent. For example, when visibility to a row in the campaign__v object is based on visibility to the campaign_target__v object.

Corresponding parent object VMOCs should have a Type of Top Level, with Meta Data Only set to True.

VMOC WHERE Clause

A VMOC’s WHERE clause is used in the Vault Query Language (VQL) query executed on the online database. It determines which specific records for the corresponding object sync down to the defined device. Any record that satisfies the conditions defined by the WHERE clause is synced. For example, to limit the number of calls synced to only include calls made in the last 90 days, the WHERE clause for the VMOC would be:

WHERE call_date__v >= LAST_DAYS:90

The following operators are not supported in VMOC WHERE clauses:

  • MAXROWS
  • SKIP
  • FIND
  • OR

See Introduction to Vault Queries for more information about VQL.

Query Logic for Calls

Call queries are treated specially, due to the large number of records and the variety of ways calls can be recorded.

To ensure group calls display the same accounts offline and online, the ipad__v platform uses the following query logic.

If the VMOC has no WHERE clause of its own, the above four queries execute separately to find calls. If there is a WHERE clause entered in the VMOC, the above queries are appended to the entered clause.

For example, if the Call WHERE clause is WHERE call_date__v >= LAST_DAYS:90, the following queries are actually executed:

  • WHERE call_date__v >= LAST_DAYS:90 AND (account__vr.name__v != null)

To have more control over the syntax of the executed WHERE clause, the &&CALLWHERE&& tag can be used to specify where the built-in Clause should be located in the query. For example, if WHERE (&&CALLWHERE&&) AND (call_date__v >= LAST_DAYS:30) is entered as the VMOC, the executed queries become:

  • WHERE (account__vr.name__v != null) AND (call_date__v >= LAST_DAYS:30)

If the number of accounts to sync is over the limit set by the analytic_account_cap__v Veeva Setting (default of 50,000), a limit is set on the number of days of calls to sync based on the capped_call_history_in_days__v Veeva Setting (default of 60).

In this case, the WHERE clause on the VMOC is ignored and the number of executed queries are as follows:

  • WHERE account__vr.name__v != null AND call_date__v >= LAST_DAYS:{callCap}
  • WHERE medical_event__vr.name__v != null AND call_date__v >= LAST_DAYS:{callCap}
  • WHERE user__sys != null AND parent_call__vr.account__vr.name__v != null AND call_date__v >= LAST_DAYS:{callCap}

Any WHERE clauses on child objects of the call are still respected.

In addition to the four WHERE clauses, the following queries run for the call2__v object:

  • SELECT id, name__v, ..., parent_call__vr.id, parent_call__vr.name__v... WHERE parent_call__v != null AND parent_call__vr.account__vr.created_by__v = null AND parent_call__vr.medical_event__vr.created_by__v= null AND account__v IN (SELECT id FROM account__v)
  • SELECT id, name__v, ..., parent_call__vr.id, parent_call__vr.name__v... WHERE parent_call__v != null AND parent_call__vr.account__vr.created_by__v= null AND parent_call__vr.medical_event__vr.created_by__v= null AND medical_event__v IN (SELECT id FROM medical_event__v)

Query Logic for the tsf__v Object

If the enable_group_filtering__v Veeva Setting is enabled, tsf__v records ignore the defined WHERE clause and are filtered by group or territory membership only.

The user's territories are queried first, descending the hierarchy. After that, the following object-specific queries run:

WHERE territory__v IN ( {ids_of_my_territories} )

Query Logic for the affiliation__v Object

The VMOC WHERE clause for the affiliation__v object is always ignored. Instead, the following queries run:

  • WHERE from_account__v IN ( Select id From account__v ) AND to_account__v IN ( Select id From account__v )

Query Logic for the sample_limit__v Object

The following queries run against sample_ limit__v records:

  • WHERE user__sys = '{userId}'
  • WHERE account__vr.name__v != null AND user__sys = null

If a specific WHERE clause is defined, it is incorporated into the above queries with an AND operator. For example, if the VMOC WHERE clause is WHERE end_date__v >= TODAY, the queries would be:

  • WHERE end_date__v >= TODAY AND (user__sys = '{userId}')
  • WHERE end_date__v >= TODAY AND (account__vr.name__v != null AND user__sys = null)

Using Multiple VMOCs on an Object

Entering a value of 1 for sync_configuration_mode__v Veeva Setting enables support for multiple Top Level or Full VMOCs for the same object. When enabled, each VMOC for a particular object and profile is used to build the offline data set. The offline data set is created via OR operators connecting the data sets returned by each VMOC and de-duplicating the results. If this setting is not set to 1, then records are not synced on objects where there are multiple VMOCs.

Before enabling multiple VMOCs for the same object, admins should consider the following:

  • Only Top Level or Full VMOCs are supported by this feature
  • Enabling multiple VMOCs for a particular object causes additional queries to run, which impacts sync time. The amount of time varies depending on the type of sync being run, the size of the object, and the complexity of the query or queries.
  • Ensure all current VMOCs are functioning correctly before enabling this feature. Once enabled, all active VMOCs are used in the sync and could potentially add unwanted data to the device.
  • The affiliation__v and child_account__v objects are not supported by this feature

Using Enhanced Sync

Selecting the enable_enhanced_sync__v check box on a VMOC enables Enhanced Sync, which transfers all newly shared records regardless of the Last Modified By date. All records, corresponding content, and attachments the user no longer has access to are removed in the sync. In contrast, traditional sync updates an object’s records on the device only if the record’s Last Modified By date is after the Last Sync date.

Sync times may be extended by enabling this feature. Only enable this feature for objects that require it.

Before enabling Enhanced Sync for a VMOC, admins should consider the following:

  • Enhanced Sync should be enabled for objects with sharing rules configured
  • Enable Enhanced Sync when the WHERE clause on an object’s VMOC is updated, or when an object’s sharing model is updated. Disable after all users have synced the change.
  • Do not enable Enhanced Sync in Related to Top Level VMOCs. This extends sync times.
  • In a master-child relationship, admins should enabled Enhanced Sync for each child object
  • VMOCs do not need to be created for object share tables except for certain Account Plan Sharing objects

If an iPad user loses access to a record referenced via another record, sync errors occur. This behavior exists regardless of whether Enhanced Sync is enabled.

Related Topics

Using Incremental Sync

Using Autosync

Tracking Sync Activity