Creating role-based permissions allows MetaLocator Enterprise customers to establish a custom access control model that follows their business rules. Group permissions are for creating teams, or "silos" in your organization that can work in parallel to create solutions in MetaLocator without interfering with each other.

Group permissions should not be used to separate data from different companies, or protect proprietary information, or by Agencies to re-sell MetaLocator to multiple separate customers. For complete data, log and analytics isolation and for Agencies reselling, contact us for details on the Agency model.

Permissions in MetaLocator are managed by a combination of user Type and Group. In general, Groups are used to limit access to data, Types are used to limit access to features.

Groups control access to the following resources:

When a user has access to a resource via group membership, it is combined with the access according to their user Type. Groups membership can not grant access that the user Type prevents. For example, Analytics Users can only access the Analytics menu. Adding an Analytics user to a group with access to Data & Interfaces will not have any effect.

This table provides a summary of permissions by user type, explained in detail below:

A common setup for a large Enterprise aligns with the following example. This example is for a company called SampleCorp. They have two webmasters that manage most web applications and data within their organization. They have two brands, Widget and Wonket that they sell. Different teams manage the Widget and Wonket data. Wonket is sold in the US and Canada. Wonket Canada data is managed by a single staff member in Canada.

SampleCorp has the following user groups:

Vicky is the Account Owner. Her role is the primary business contact for MetaLocator. She signed the Enterprise contract and is in charge of the MetaLocator engagement with her company SampleCorp. Her email address was used when the MetaLocator account was created. She has access to all users, data, categories, fields and Interface settings. Her privileged access includes the ability to access billing information and the ability to upgrade, downgrade or cancel the account.

Tim & Brit are Administrators. They are Webmasters at their company. They have no groups assigned. Because they are Administrators with no groups assigned, they have access to all users, data, categories, fields and Interface settings. They can not access billing information. They also can not upgrade, downgrade or cancel the account. They can create new users and add them to any (or no) group. They can also change groups for users, data, categories, fields and Interfaces.

Adam is a Group Administrator. He manages only the Widget Brand at SampleCorp. He is in the Widget Brand group. He can access data, categories, fields and Interfaces assigned to the Widget Brand groups only. He can create new users, data, categories and Interfaces but they are automatically placed in the Widget Brand group. As a Group Administrator, Adam can not create fields. Creating fields is the role of Administrators or the Account Owner only. This special limitation avoids unregulated data definition actions at the group level.

Nasir is a Manager. He is responsible for maintaining data for Widget Brand at SampleCorp. He collects a list of dealers every month and keeps the data in MetaLocator correct and up to date. He is in the Widget Brand group. This group has access to location records in the Widget Brand group only. Michael can not create users because he a Manager user. He can't see the Interfaces or categories because he is a Manager user. When he edits a location record, he sees all standard fields, plus a custom field that applies to only Widget Brand. That custom field was created by Adam.

When Nasir, the Manager for Widget Brand, imports data the records he creates are automatically placed in the Widget Brand group.

Nasir can not create categories, fields or Interfaces as a manager.

Aria is also a Manager. She is responsible for data for the Wonket brand data. She is in the Wonket Brand group. This group has access to location records in the Wonket Brand group only. Aria can not create users because he a Manager user. She can't see the Interfaces or categories because she is a Manager user. When she edits a location record, she sees standard fields only and no custom fields since no custom fields are in the Wonket Brand group.

SampleCorp's User Manager appears as follows:

Michael is the sole staff member in Canada for the Wonket Brand. He is a Manager user with access to Canada only. He is in the Wonket Brand group. Michael can import only records in Canada since he is a Manager limited to Canada. If he adds data without a TLD column, it is assigned the CA TLD. Any records with a TLD other than CA are ignored. Similar to Aria, when Michael imports data, it is automatically created in the Wonket Brand group.

Michael's setup is shown below, notice the Country and Group options:

Administrators can not be added to groups. Group Administrators must be in at least one group. Group Administrators can not create, modify or delete fields. Creating fields is the role of un-grouped Administrators or the Account Owner only. This special limitation avoids data definition actions at the group level that would impact other users. Administrators can also create tables while Group Administrators can not.

Group Administrators in one or more groups can only manage data, users, categories and interfaces in their groups. They can only remove these resources from groups they have access to. If they remove these resources from all groups they have access to, they are automatically added to all groups they have access to. This avoids the situation where a user saves a record and has lost access by removing all groups.

In the example above, you could create users with overlapping access. E.g. User A is in groups 1 and 2 and User B is in groups 2 and 3. They both have access to Group 2, meaning their work could impact each other. This occurs in access to data, categories and interfaces. In general, try to avoid overlapping access unless required by your business model and understood by users with overlapping access. Access to fields is an exception to this caution where shared access by Group Administrators and Managers is often required and preferred. E.g. most users want access to the Address, City and State fields. Creating a "Shared Fields" group that manages this overlapping access is recommended.

When Aria, the Manager in the Wonket group, edits a location record she can add or remove records from the categories she has access to. She has access to categories in the Wonket group. She can remove any categories from a location record which she has access to, but if she removes all of her categories and tries to save the record, it will be added to all groups she has access to, in this case, the Wonket group. This works the same way during a bulk import. If Aria specifies no groups during import, they are assigned all groups she has access to, in this case, the Wonket group. This strategy limits her potential impact to only the Wonket group.

When users in groups are modifying data, they are only able to access fields according to their group membership. In the example above, Adam is a Group Administrator in the Widget Group. When he creates or edits a location in the back-end, he only sees fields in his group. In the below example, we see two custom fields, one in the Widget Group, and one in both the Widget and Wonket groups. In this example account there are other fields present in only the Wonket group, not showing to Adam because he is not in that group.

Field access can be controlled by assigning groups to a specific field as shown in the Field Details.

Fields can be associated with individual groups by selecting them under Select Groups. If a field should available to all groups, including any groups added in the future, check the All Groups checkbox. When this box is checked, the groups selected under Select Groups have no effect.

To create a group, go to the User Manager as shown,

Then click User Groups in the upper right ellipses menu. That button is available to Owners, Administrators and Group Administrators of Enterprise accounts only.

Click New, and provide a group name and any required notes.

When groups are deleted, the group is automatically removed from any associated resources. Resources in those deleted groups will not be otherwise affected.

When users are deleted, the ownership record for that user is removed from any associated resources. Resources created by that user will still exist.

If a user specifies a user_group_id column in the import data file, it can control which groups are assigned during import. Any records without a user_group_id value will inherit all of the current user's groups. If a user_group_id column is not provided, groups will not be changed during import. Any user_group_id's not available to that user will be ignored. The user_group_id can be specified by the MetaLocator-assigned Group ID or the Group Name as shown in the Group Manager. The screenshot below shows the user_group_id column populated with valid variations on the user_group_id format:

See this article on Import Mapping.

Interfaces can be added and removed from Groups from the Interfaces bulk actions menu. When interfaces are added to a group they

See the Set Groups button as shown:

In the subsequent screen, you can choose to set groups by replacing, adding or removing the selected groups from the drop-down list.

When creating or editing categories, the Group can be set on the Category Options Tab as shown:

Be sure not to confuse Groups with the Group Name. The Category Group Name is for grouping like categories into groups and is not related to permissions. E.g. Services might be a Category Group Name, shared by categories called Repair, Cleaning and Disposal.

Category Groups can also be set in bulk, using the bulk actions menu