MetaLocator can allow your internal teams to work within a single Enterprise account while not interfering with each others work. This requires a MetaLocator Teams engagement, which is available in Enterprise and higher accounts.
Having success with MetaLocator and multiple, independent teams requires a bit of planning to ensure a good setup. Some areas of consideration include:
Group Permissions. What groups will be created, which users will have access to each group, users that might have access to multiple groups
Data Structure. What fields will be shared across groups and which will be limited to a specific group.
Data Import. Where data will be coming from, including support for multiple data sources.
Keys. What shared data field, or fields comprise a unique identifier for updating data in MetaLocator.
In this guide, we will discuss the strategic planning aspects of each decision, with references to more practical implementation articles.
Group Permissions are documented extensively in this support system. Choosing groups wisely at the outset is a critical step in a Teams implementation. Groups should identify teams of concern within your organization. These are groups of people, and the groups you create in MetaLocator should mirror the scope of those people in your organization. The groups should be grounded in the actual people that do the work. Avoid creating an overly complex group structure in MetaLocator that mirrors a hypothetical organizational hierarchy. Focus on the implementation, not the management hierarchy.
A typical implementation is the creation of groups based on brands within the Enterprise. The location data differs by brand and the locators differ by brand so it makes sense to create groups based on the brand.
Users within Groups
The most common implementation in MetaLocator teams is to have one Group Administrator within each group that can create Interfaces and Categories for the group. Then, within the group there are Managers who can import and update data. One additional consideration is country managers. These are managers that are limited by group and a country. This is useful when team members manage data for a specific country and their contributions should not influence outside their country.
Above the Group Administrators you can position an Administrator who has access to all groups. This is typically a centralized IT role, like a database administrator or IT manager that is commonly assigned tasks that can influence the entire Enterprise.
Some groups might have access to certain fields that only relate to their area. Access to a field quite simply controls whether it is available to edit when importing data or when manually editing data. This conveniently limits the size of the form to only fields that matter to that user when editing a location. Similarly, when importing and exporting the columns are limited to those which matter to that group.
Address fields, like city,state and postal code are normally shared across groups, however that sharing must be explicitly set in the field settings for each field. Certain system fields like latitude and longitude, published state, name and type are accessible to all groups.
Data can be imported into MetaLocator from multiple different sources simultaneously. The data can flow in from spreadsheets, SalesForce, Google Drive and so forth all at different times and in different groups. When data is imported by a user in a group, the data is automatically added to those groups, unless the user specified the target groups in the data source. This means you can have each team using their own data source and import methods without impacting each other.
It is also possible to collect data from multiple sources into MetaLocator where multiple data sources combine to update a single record. This is possible where an External Key is in use. This allows Group A to refer to a specific record using the same "ID number" as Group B, then as Group A and B make updates, they can impact the same record. In this scenario, it is important to ensure that access to fields is appropriately delegated so that Group B does not overwrite Group A's work. In some cases, that is desirable as when creating workflows, where Group B is editing & approving group A's work.