Understand Location Data
Work.com uses Location to associate Employees to physical and abstract locations. Existing solutions may already have an alternate data model that tracks employee locations. To apply the full power of Work.com, solutions may need to correlate or synchronize their data with Location data.
Locations can be physical sites, such as a building, a farm, a factory, or any location where your employees normally congregate during their regular workday. Locations can also be abstractions, representing an aggregation of child locations that should be viewed together because of a shared characteristic, such as locations belonging to the same sales region. If your solution already uses a different entity or data source to define locations, and you need to correlate this information with Work.com, you’ll need to synchronize your data with the Location object. Synchronization strategies similar to those described for synchronizing Employee data can also be used for Location data.
Because Location is modeled and used as a hierarchical tree structure, it’s important to be able to efficiently query subtrees within it. This is made possible using the wkcc__LocationPath__c field, along with the Location trigger. wkcc__LocationPath__c is of the form “<level one id>,<level two id>,<level three id>”, and so forth.
Treat wkcc__LocationPath__c as a read-only field. Only Salesforce should modify the location path for a location.
The following SOQL example queries for a subtree in a Location hierarchy.
A normal flow would be to query for the location at the top of the subtree you’re interested in, and then query as:
See Also