Source: https://vaultcrmhelp.veeva.com/doc/Content/CRM_topics/Getting_Started/MobileDeviceSetup/Sync/VMOCs.htm

## Using VMobile Object Configurations

VMobile Object Configurations (VMOCs) control which objects and records are synced to mobile 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](UsingIncrementalSync.htm) to function correctly.

### Attachments

The Include Attachments checkbox 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 checkbox in the Options list in the object details.

Deleting and uploading attachments on mobile platforms is not supported.

See [Managing Attachments Offline](../DocumentsAttachments/ManagingDocsOffline.htm) 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. The following picklist values are available:

| Platform | Picklist Label | API Name |
| --- | --- | --- |
| CRM Desktop (Windows) | CRM\_Desktop\_Windows | crm\_engage\_\_v |
| iPad | iPad | ipad\_\_v |
| iPhone | iPhone | iphone\_\_v |
| Windows | Windows | winmodern\_\_v |

### 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 objects.

#### Top Level Sync

Top Level Object Sync is reserved for parent objects in Vault CRM, including Account, Medical Event, and User. The Include Related Objects checkbox 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 does 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. During incremental syncs, updated child records sync regardless of whether the parent record is updated.

#### Child and Parent Row Sync

This is used when a child or related object controls the visibility of the parent or main object. For example, when visibility to a row in the campaign\_\_v object is based on visibility to the campaign\_target\_\_v object.

Corresponding parent or main object VMOCs must 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

Veeva does not recommend using the CONTAINS operator in the WHERE clause for message\_\_v VMOCs.

The following operators are not supported in VMOC WHERE clauses:

* MAXROWS
* SKIP
* FIND
* OR

The OR operator can only be used to compare conditions for the same object. See [VQL documentation](https://developer.veevavault.com/vql/#or) for more information.

The following MetaVQL parameters are supported in VMOC WHERE clauses:

* @@LAST\_MODIFIED\_DATE@@ - The last sync timestamp for the mobile user
* @@SYNCED\_ACCOUNTS@@ – The account IDs of accounts the mobile user has access to. Used when customers have additional filtering criteria on the Account VMOC and want to use the same criteria for other VMOCs involving accounts.
* @@USER\_APP\_PROFILE\_ID@@ - The ID of the mobile user's assigned [application profile](../../SettingUp/ApplicationProfiles.htm)
* @@USER\_ID@@ - The mobile user's ID
* @@USERS\_IN\_USER\_TERRITORY@@ - The user IDs for all users in the mobile user's assigned territories and child territories, including the mobile user
* @@USER\_LABEL\_SET@@ - The ID of the mobile user's assigned label set
* @@USER\_LANGUAGE\_CODE@@ - The mobile user's language code
* @@USER\_PRODUCTS@@ – The IDs of products assigned to the mobile user in My Setup Products. Used to sync records related only to products assigned to the user, for example, syncing products for Product Metrics.
* @@USER\_PROFILE\_ID@@ - The ID of the mobile user's assigned security profile
* @@USER\_TERRITORY\_IDS@@ - Comma-delimited list of the IDs of the mobile user's assigned territories
* @@USER\_TERRITORY\_NAMES@@ - Comma-delimited list of the names of the mobile user's assigned territories, including child territories

See [Introduction to Vault Queries](https://developer.veevavault.com/vql/#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 checkbox 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 ir Enhanced Sync is enabled.

### Related Topics

[Using Incremental Sync](UsingIncrementalSync.htm)

[Using Autosync](UsingAutosync.htm)

[Tracking Sync Activity](TrackSyncActivity.htm)
